{"items":[{"id":"NVI-00008092","kind":"vulnerability","title":"Information Disclosure due to Out-of-scope Site Resolution","revision":4,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected.","NVD lastModified does not establish freshness of every associated CPE record."],"lifecycle":"active","identifiers":["GHSA-jq6g-4v5m-wm9r","CVE-2023-38499"],"plain_summary":"OSV carries this publisher advisory for typo3/cms-core, typo3/cms-core, typo3/cms-core, typo3/cms-core. This is an aggregated source copy; consult the original publisher and compare update dates.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"The original advisory lists fixed boundaries 9.5.42 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 10.4.39 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 11.5.30 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 12.4.4 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.","source_ids":["sr-1225a6d322b3d32448e9e09287c71b6c"],"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-06-17T06:10:35.443Z","value":"3.7 LOW (3.1)","meaning":"security-advisories@github.com severity; no combined Null risk score.","source_id":"sr-1e2367e707fc81f6c5fbb497dbf3e6b3"},{"kind":"CVSS","as_of":"2026-06-17T06:10:35.443Z","value":"5.3 MEDIUM (3.1)","meaning":"nvd@nist.gov severity; no combined Null risk score.","source_id":"sr-1e2367e707fc81f6c5fbb497dbf3e6b3"},{"kind":"EPSS","as_of":"2026-11-01T12:00:16.000Z","value":"1.069%","meaning":"FIRST EPSS model v2026.06.15; exploitation probability over 30 days, percentile 0.64834. Missing scores are unknown.","source_id":"sr-1225a6d322b3d32448e9e09287c71b6c"}],"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-f5869e7a3c1b04b6ff5f3d5a89a5f340","url":"https://github.com/advisories/GHSA-jq6g-4v5m-wm9r","basis":"vendor_advisory","notes":"GitHub-origin advisory, CC-BY-4.0; OSV is an aggregate copy, not independent corroboration.","title":"GHSA-jq6g-4v5m-wm9r","publisher":"GitHub Advisory Database via OSV","observed_at":"2026-10-31T21:42:30.968Z"},{"id":"sr-1e2367e707fc81f6c5fbb497dbf3e6b3","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-38499","basis":"official_catalog","notes":"This product uses data from the NVD API but is not endorsed or certified by the NVD.","title":"CVE-2023-38499","publisher":"NIST National Vulnerability Database","observed_at":"2026-11-02T02:21:47.316Z"},{"id":"sr-1225a6d322b3d32448e9e09287c71b6c","url":"https://www.first.org/epss/data.html","basis":"official_catalog","notes":"FIRST EPSS; probability of exploitation in the next 30 days, not local compromise. Dataset date/model retained; FIRST services terms apply.","title":"CVE-2023-38499","publisher":"FIRST EPSS","observed_at":"2026-11-01T14:27:48.610Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 9.4.0; fixed 9.5.42"]},{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 10.0.0; fixed 10.4.39"]},{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 11.0.0; fixed 11.5.30"]},{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 12.0.0; fixed 12.4.4"]}],"null_published_at":"2026-11-03T17:49:18.475Z","source_updated_at":"2024-02-16T08:13:58.146Z","source_disclosed_at":"2023-07-25T18:25:52.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"Dated EPSS estimate updated; this is not a new disclosure or proof of exploitation.","null_first_observed_at":"2026-10-31T21:42:30.968Z"},{"id":"NVI-00008092","kind":"vulnerability","title":"Information Disclosure due to Out-of-scope Site Resolution","revision":3,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected.","NVD lastModified does not establish freshness of every associated CPE record."],"lifecycle":"active","identifiers":["GHSA-jq6g-4v5m-wm9r","CVE-2023-38499"],"plain_summary":"OSV carries this publisher advisory for typo3/cms-core, typo3/cms-core, typo3/cms-core, typo3/cms-core. This is an aggregated source copy; consult the original publisher and compare update dates.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"The original advisory lists fixed boundaries 9.5.42 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 10.4.39 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 11.5.30 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 12.4.4 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.","source_ids":["sr-907b78e6cc3b948e64a4f642d596d387"],"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-06-17T06:10:35.443Z","value":"3.7 LOW (3.1)","meaning":"security-advisories@github.com severity; no combined Null risk score.","source_id":"sr-1e2367e707fc81f6c5fbb497dbf3e6b3"},{"kind":"CVSS","as_of":"2026-06-17T06:10:35.443Z","value":"5.3 MEDIUM (3.1)","meaning":"nvd@nist.gov severity; no combined Null risk score.","source_id":"sr-1e2367e707fc81f6c5fbb497dbf3e6b3"},{"kind":"EPSS","as_of":"2026-10-31T12:00:27.000Z","value":"1.069%","meaning":"FIRST EPSS model v2026.06.15; exploitation probability over 30 days, percentile 0.64835. Missing scores are unknown.","source_id":"sr-907b78e6cc3b948e64a4f642d596d387"}],"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-f5869e7a3c1b04b6ff5f3d5a89a5f340","url":"https://github.com/advisories/GHSA-jq6g-4v5m-wm9r","basis":"vendor_advisory","notes":"GitHub-origin advisory, CC-BY-4.0; OSV is an aggregate copy, not independent corroboration.","title":"GHSA-jq6g-4v5m-wm9r","publisher":"GitHub Advisory Database via OSV","observed_at":"2026-10-31T21:42:30.968Z"},{"id":"sr-1e2367e707fc81f6c5fbb497dbf3e6b3","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-38499","basis":"official_catalog","notes":"This product uses data from the NVD API but is not endorsed or certified by the NVD.","title":"CVE-2023-38499","publisher":"NIST National Vulnerability Database","observed_at":"2026-11-02T02:21:47.316Z"},{"id":"sr-907b78e6cc3b948e64a4f642d596d387","url":"https://www.first.org/epss/data.html","basis":"official_catalog","notes":"FIRST EPSS; probability of exploitation in the next 30 days, not local compromise. Dataset date/model retained; FIRST services terms apply.","title":"CVE-2023-38499","publisher":"FIRST EPSS","observed_at":"2026-10-31T22:06:03.704Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 9.4.0; fixed 9.5.42"]},{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 10.0.0; fixed 10.4.39"]},{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 11.0.0; fixed 11.5.30"]},{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 12.0.0; fixed 12.4.4"]}],"null_published_at":"2026-11-03T02:33:09.148Z","source_updated_at":"2024-02-16T08:13:58.146Z","source_disclosed_at":"2023-07-25T18:25:52.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"Dated EPSS estimate updated; this is not a new disclosure or proof of exploitation.","null_first_observed_at":"2026-10-31T21:42:30.968Z"},{"id":"NVI-00008092","kind":"vulnerability","title":"Information Disclosure due to Out-of-scope Site Resolution","revision":2,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected.","NVD lastModified does not establish freshness of every associated CPE record."],"lifecycle":"active","identifiers":["GHSA-jq6g-4v5m-wm9r","CVE-2023-38499"],"plain_summary":"OSV carries this publisher advisory for typo3/cms-core, typo3/cms-core, typo3/cms-core, typo3/cms-core. This is an aggregated source copy; consult the original publisher and compare update dates.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"The original advisory lists fixed boundaries 9.5.42 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 10.4.39 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 11.5.30 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 12.4.4 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.","source_ids":["sr-1e2367e707fc81f6c5fbb497dbf3e6b3"],"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-06-17T06:10:35.443Z","value":"3.7 LOW (3.1)","meaning":"security-advisories@github.com severity; no combined Null risk score.","source_id":"sr-1e2367e707fc81f6c5fbb497dbf3e6b3"},{"kind":"CVSS","as_of":"2026-06-17T06:10:35.443Z","value":"5.3 MEDIUM (3.1)","meaning":"nvd@nist.gov severity; no combined Null risk score.","source_id":"sr-1e2367e707fc81f6c5fbb497dbf3e6b3"}],"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-f5869e7a3c1b04b6ff5f3d5a89a5f340","url":"https://github.com/advisories/GHSA-jq6g-4v5m-wm9r","basis":"vendor_advisory","notes":"GitHub-origin advisory, CC-BY-4.0; OSV is an aggregate copy, not independent corroboration.","title":"GHSA-jq6g-4v5m-wm9r","publisher":"GitHub Advisory Database via OSV","observed_at":"2026-10-31T21:42:30.968Z"},{"id":"sr-1e2367e707fc81f6c5fbb497dbf3e6b3","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-38499","basis":"official_catalog","notes":"This product uses data from the NVD API but is not endorsed or certified by the NVD.","title":"CVE-2023-38499","publisher":"NIST National Vulnerability Database","observed_at":"2026-11-02T02:21:47.316Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 9.4.0; fixed 9.5.42"]},{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 10.0.0; fixed 10.4.39"]},{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 11.0.0; fixed 11.5.30"]},{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 12.0.0; fixed 12.4.4"]}],"null_published_at":"2026-11-02T10:00:44.511Z","source_updated_at":"2024-02-16T08:13:58.146Z","source_disclosed_at":"2023-07-25T18:25:52.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"Source facts changed; compare the preserved prior revision.","null_first_observed_at":"2026-10-31T21:42:30.968Z"},{"id":"NVI-00008092","kind":"vulnerability","title":"Information Disclosure due to Out-of-scope Site Resolution","revision":1,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected."],"lifecycle":"active","identifiers":["GHSA-jq6g-4v5m-wm9r","CVE-2023-38499"],"plain_summary":"OSV carries this publisher advisory for typo3/cms-core, typo3/cms-core, typo3/cms-core, typo3/cms-core. This is an aggregated source copy; consult the original publisher and compare update dates.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"The original advisory lists fixed boundaries 9.5.42 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 10.4.39 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 11.5.30 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null},{"summary":"The original advisory lists fixed boundaries 12.4.4 for typo3/cms-core. Confirm the publisher’s latest guidance.","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"action_type":"vendor_patch","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":[],"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-f5869e7a3c1b04b6ff5f3d5a89a5f340","url":"https://github.com/advisories/GHSA-jq6g-4v5m-wm9r","basis":"vendor_advisory","notes":"GitHub-origin advisory, CC-BY-4.0; OSV is an aggregate copy, not independent corroboration.","title":"GHSA-jq6g-4v5m-wm9r","publisher":"GitHub Advisory Database via OSV","observed_at":"2026-10-31T21:42:30.968Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 9.4.0; fixed 9.5.42"]},{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 10.0.0; fixed 10.4.39"]},{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 11.0.0; fixed 11.5.30"]},{"certainty":"source_listed","source_ids":["sr-f5869e7a3c1b04b6ff5f3d5a89a5f340"],"technology":"typo3/cms-core","known_exclusions":[],"conditions_summary":"> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5)\n\n### Problem\nIn multi-site scenarios, enumerating the HTTP query parameters `id` and `L` allowed out-of-scope access to rendered content in the website frontend. For instance, this allowed visitors to access content of an internal site by adding handcrafted query parameters to the URL of a site that was publicly available.\n\n### Solution\nUpdate to TYPO3 versions 9.5.42 ELTS, 10.4.39 ELTS, 11.5.30, 12.4.4 that fix the problem described above.\n\n> ℹ️ **Strong security defaults - Manual actions required**\n> Resolving sites by the `id` and `L` HTTP query parameters is now denied per default. However, it is still allowed to resolve a particular page by e.g. `https://example.org/?id=123&L=0` - as long as the `page-id 123` is in the scope of the site configured for the `base-url example.org`.\n> The new feature flag `security.frontend.allowInsecureSiteResolutionByQueryParameters` - which is disabled per default - can be used to reactivate the previous behavior.\n\n### Credits\nThanks to Garvin Hicking who reported this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke who fixed the is","public_affected_ranges":["ECOSYSTEM: introduced 12.0.0; fixed 12.4.4"]}],"null_published_at":"2026-10-31T22:13:22.829Z","source_updated_at":"2024-02-16T08:13:58.146Z","source_disclosed_at":"2023-07-25T18:25:52.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-10-31T21:42:30.968Z"}],"next_cursor":null,"snapshot_revision":"42594"}