{"items":[{"id":"NVI-00013776","kind":"vulnerability","title":"MariaDB Connector/J does not enforce allowLocalInfile=false  on server-initiated LOCAL INFILE requests","revision":1,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected."],"lifecycle":"active","identifiers":["GHSA-wxmm-q36w-r9xj","CVE-2026-61700"],"plain_summary":"GitHub lists this reviewed advisory for org.mariadb.jdbc:mariadb-java-client, org.mariadb.jdbc:mariadb-java-client, org.mariadb.jdbc:mariadb-java-client, org.mariadb.jdbc:mariadb-java-client. Published version ranges and source prerequisites are shown below; this is not an inspection of a visitor’s application.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.","source_ids":["sr-00ef4fc37bcd9eb765e93cc735d8d4b9"],"action_type":"investigate","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null}],"schema_version":"1.1.0","source_metrics":[{"kind":"CVSS","as_of":"2026-09-17T16:29:55.000Z","value":"3.7 low","meaning":"GitHub source severity; exploitability and local consequence require separate evidence.","source_id":"sr-00ef4fc37bcd9eb765e93cc735d8d4b9"}],"why_it_matters":"Published affected context helps an owner decide what evidence to gather. This report has not examined your application.","related_sources":[{"id":"sr-00ef4fc37bcd9eb765e93cc735d8d4b9","url":"https://github.com/advisories/GHSA-wxmm-q36w-r9xj","basis":"vendor_advisory","notes":"GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.","title":"GHSA-wxmm-q36w-r9xj","publisher":"GitHub Advisory Database","observed_at":"2026-11-01T19:09:30.244Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-00ef4fc37bcd9eb765e93cc735d8d4b9"],"technology":"org.mariadb.jdbc:mariadb-java-client","known_exclusions":[],"conditions_summary":"## Summary\n\nMariaDB Connector/J does not enforce `allowLocalInfile=false` when \nprocessing server-initiated LOCAL INFILE requests (protocol packet \ntype `0xfb`). However, exploitation is constrained: the server can \nonly request the exact filename the client already included in its \n`LOAD DATA LOCAL INFILE` query, it cannot redirect to arbitrary paths.\n\n## Details\n\nWhen a client executes `LOAD DATA LOCAL INFILE '/path/to/file'`, the \nconnector sends the filename to the server as part of the COM_QUERY. \nA rogue or MitM server responds with a `0xfb` packet echoing that \nsame filename. The connector, without checking `allowLocalInfile`, \ntransmits the file content.\n\nThe bypass is therefore limited to the file the application itself \nintended to load. The attacker cannot escalate to other files \n(e.g. `/etc/passwd`) unless the application's own query targets them.\n\nThe real-world risk is:\n- An application that uses `LOAD DATA LOCAL INFILE` on potentially \n  sensitive files (credentials, exports, configs) and connects over \n  an untrusted network.\n- `allowLocalInfile=false` is supposed to disable this entire \n  mechanism as a defense-in-depth measure, but the flag is ignored.\n\n## Impact","public_affected_ranges":["< 2.7.14"]},{"certainty":"source_listed","source_ids":["sr-00ef4fc37bcd9eb765e93cc735d8d4b9"],"technology":"org.mariadb.jdbc:mariadb-java-client","known_exclusions":[],"conditions_summary":"## Summary\n\nMariaDB Connector/J does not enforce `allowLocalInfile=false` when \nprocessing server-initiated LOCAL INFILE requests (protocol packet \ntype `0xfb`). However, exploitation is constrained: the server can \nonly request the exact filename the client already included in its \n`LOAD DATA LOCAL INFILE` query, it cannot redirect to arbitrary paths.\n\n## Details\n\nWhen a client executes `LOAD DATA LOCAL INFILE '/path/to/file'`, the \nconnector sends the filename to the server as part of the COM_QUERY. \nA rogue or MitM server responds with a `0xfb` packet echoing that \nsame filename. The connector, without checking `allowLocalInfile`, \ntransmits the file content.\n\nThe bypass is therefore limited to the file the application itself \nintended to load. The attacker cannot escalate to other files \n(e.g. `/etc/passwd`) unless the application's own query targets them.\n\nThe real-world risk is:\n- An application that uses `LOAD DATA LOCAL INFILE` on potentially \n  sensitive files (credentials, exports, configs) and connects over \n  an untrusted network.\n- `allowLocalInfile=false` is supposed to disable this entire \n  mechanism as a defense-in-depth measure, but the flag is ignored.\n\n## Impact","public_affected_ranges":[">= 3.0.0, < 3.3.5"]},{"certainty":"source_listed","source_ids":["sr-00ef4fc37bcd9eb765e93cc735d8d4b9"],"technology":"org.mariadb.jdbc:mariadb-java-client","known_exclusions":[],"conditions_summary":"## Summary\n\nMariaDB Connector/J does not enforce `allowLocalInfile=false` when \nprocessing server-initiated LOCAL INFILE requests (protocol packet \ntype `0xfb`). However, exploitation is constrained: the server can \nonly request the exact filename the client already included in its \n`LOAD DATA LOCAL INFILE` query, it cannot redirect to arbitrary paths.\n\n## Details\n\nWhen a client executes `LOAD DATA LOCAL INFILE '/path/to/file'`, the \nconnector sends the filename to the server as part of the COM_QUERY. \nA rogue or MitM server responds with a `0xfb` packet echoing that \nsame filename. The connector, without checking `allowLocalInfile`, \ntransmits the file content.\n\nThe bypass is therefore limited to the file the application itself \nintended to load. The attacker cannot escalate to other files \n(e.g. `/etc/passwd`) unless the application's own query targets them.\n\nThe real-world risk is:\n- An application that uses `LOAD DATA LOCAL INFILE` on potentially \n  sensitive files (credentials, exports, configs) and connects over \n  an untrusted network.\n- `allowLocalInfile=false` is supposed to disable this entire \n  mechanism as a defense-in-depth measure, but the flag is ignored.\n\n## Impact","public_affected_ranges":[">= 3.4.0, < 3.4.3"]},{"certainty":"source_listed","source_ids":["sr-00ef4fc37bcd9eb765e93cc735d8d4b9"],"technology":"org.mariadb.jdbc:mariadb-java-client","known_exclusions":[],"conditions_summary":"## Summary\n\nMariaDB Connector/J does not enforce `allowLocalInfile=false` when \nprocessing server-initiated LOCAL INFILE requests (protocol packet \ntype `0xfb`). However, exploitation is constrained: the server can \nonly request the exact filename the client already included in its \n`LOAD DATA LOCAL INFILE` query, it cannot redirect to arbitrary paths.\n\n## Details\n\nWhen a client executes `LOAD DATA LOCAL INFILE '/path/to/file'`, the \nconnector sends the filename to the server as part of the COM_QUERY. \nA rogue or MitM server responds with a `0xfb` packet echoing that \nsame filename. The connector, without checking `allowLocalInfile`, \ntransmits the file content.\n\nThe bypass is therefore limited to the file the application itself \nintended to load. The attacker cannot escalate to other files \n(e.g. `/etc/passwd`) unless the application's own query targets them.\n\nThe real-world risk is:\n- An application that uses `LOAD DATA LOCAL INFILE` on potentially \n  sensitive files (credentials, exports, configs) and connects over \n  an untrusted network.\n- `allowLocalInfile=false` is supposed to disable this entire \n  mechanism as a defense-in-depth measure, but the flag is ignored.\n\n## Impact","public_affected_ranges":[">= 3.5.0, < 3.5.9"]}],"null_published_at":"2026-11-02T10:00:37.146Z","source_updated_at":"2026-09-17T16:29:55.000Z","source_disclosed_at":"2026-09-17T16:29:53.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"First indexed by Null; source disclosure date is shown separately.","null_first_observed_at":"2026-11-01T19:09:30.244Z"}],"next_cursor":null,"snapshot_revision":"42594"}