Every CVESearch/Get API key

GHSA-q683-8468-r6h6

WebauthnAuthenticator leaks sensitive HTTP headers through INFO-level logs

6.6 MediumFix available

GHSA-q683-8468-r6h6 is a medium vulnerability (CVSS 6.6) in web-auth/webauthn-symfony-bundle, published June 26, 2026. No source lists public exploit code. Fixed in web-auth/webauthn-symfony-bundle 5.3.4.

What does this mean?
Severity
6.6 MediumCVSS 4.0, GitHub Advisories
Exploit chance
UnscoredNo EPSS score yet
Exploitation
None knownNot on CISA’s or ENISA’s lists

Description

Impact

Webauthn\Bundle\Security\Http\Authenticator\WebauthnAuthenticator logs the full Symfony\Component\HttpFoundation\Request object inside the log context of both onAuthenticationSuccess() and onAuthenticationFailure() at INFO level:

$this->logger->info('User has been authenticated successfully with Webauthn.', [
    'request' => $request,
    'firewallName' => $firewallName,
    'identifier' => $token->getUserIdentifier(),
]);

$this->logger->info('Webauthn authentication request failed.', [
    'request' => $request,
    'exception' => $exception,
]);

Request::__toString() returns the raw HTTP message, including every request header. As soon as the configured logger normalises or stringifies the context (default behaviour for LineFormatter, JsonFormatter via NormalizerFormatter, etc.), sensitive headers such as Cookie (session identifier), Authorization and any custom auth header are written to the log stream in clear text.

Applications that forward logs to centralised platforms (ELK, Splunk, Datadog and similar) are particularly exposed: log access is typically broader than application access, which can allow log readers to hijack authenticated sessions.

Affected versions

Every release prior to 5.3.4 is affected.

Patches

The fix removes the full Request object from the log context and keeps only non-sensitive fields (request path, method, firewall name, user identifier). It is shipped in 5.3.4. Older branches will not receive a backport; users on those branches should upgrade to 5.3.4+ or apply one of the workarounds below.

Workarounds

Until the upgrade is applied, projects can:

  1. Raise the minimum log level for the WebAuthn authenticator above INFO so these two log records are not emitted in production.
  2. Configure their Monolog processor/formatter to strip the request key from the context of these records before they are written.

Credit

Reported by Kay Joosten (Dawn Technology), maintainer of Stepup-Webauthn.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
High
Integrity
None
Availability
None

Affected packages

Affected packages
PackageAffectedFixed
web-auth/webauthn-symfony-bundle
Packagist
before 5.3.4
5.3.4
web-auth/webauthn-symfony-bundle
Packagist
before 5.3.4, plus listed versions
4.1.04.1.14.1.24.1.34.1.4
Show 45 moreShow less
4.1.54.2.04.2.14.2.24.2.34.3.04.3.14.4.04.4.14.4.24.4.34.5.04.5.14.5.24.6.04.6.14.6.24.6.34.6.44.7.04.7.14.7.24.7.34.7.44.7.54.7.64.7.74.7.84.7.94.8.04.8.14.8.24.8.34.8.44.8.54.8.64.8.74.9.04.9.14.9.24.9.35.0.05.0.15.1.05.1.1
5.3.4

What each source reports

GitHub Advisories Score used6.6

WebauthnAuthenticator leaks sensitive HTTP headers through INFO-level logs

Impact

Webauthn\Bundle\Security\Http\Authenticator\WebauthnAuthenticator logs the full Symfony\Component\HttpFoundation\Request object inside the log context of both onAuthenticationSuccess() and onAuthenticationFailure() at INFO level:

$this->logger->info('User has been authenticated successfully with Webauthn.', [
    'request' => $request,
    'firewallName' => $firewallName,
    'identifier' => $token->getUserIdentifier(),
]);

$this->logger->info('Webauthn authentication request failed.', [
    'request' => $request,
    'exception' => $exception,
]);

Request::__toString() returns the raw HTTP message, including every request header. As soon as the configured logger normalises or stringifies the context (default behaviour for LineFormatter, JsonFormatter via NormalizerFormatter, etc.), sensitive headers such as Cookie (session identifier), Authorization and any custom auth header are written to the log stream in clear text.

Applications that forward logs to centralised platforms (ELK, Splunk, Datadog and similar) are particularly exposed: log access is typically broader than application access, which can allow log readers to hijack authenticated sessions.

Affected versions

Every release prior to 5.3.4 is affected.

Patches

The fix removes the full Request object from the log context and keeps only non-sensitive fields (request path, method, firewall name, user identifier). It is shipped in 5.3.4. Older branches will not receive a backport; users on those branches should upgrade to 5.3.4+ or apply one of the workarounds below.

Workarounds

Until the upgrade is applied, projects can:

  1. Raise the minimum log level for the WebAuthn authenticator above INFO so these two log records are not emitted in production.
  2. Configure their Monolog processor/formatter to strip the request key from the context of these records before they are written.

Credit

Reported by Kay Joosten (Dawn Technology), maintainer of Stepup-Webauthn.

Record
GHSA-q683-8468-r6h6
CVSS 4.0
6.6 MediumCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
Weakness
CWE-200, CWE-532
Updated
2026-11-02
OSV6.6

WebauthnAuthenticator leaks sensitive HTTP headers through INFO-level logs

Impact

Webauthn\Bundle\Security\Http\Authenticator\WebauthnAuthenticator logs the full Symfony\Component\HttpFoundation\Request object inside the log context of both onAuthenticationSuccess() and onAuthenticationFailure() at INFO level:

$this->logger->info('User has been authenticated successfully with Webauthn.', [
    'request' => $request,
    'firewallName' => $firewallName,
    'identifier' => $token->getUserIdentifier(),
]);

$this->logger->info('Webauthn authentication request failed.', [
    'request' => $request,
    'exception' => $exception,
]);

Request::__toString() returns the raw HTTP message, including every request header. As soon as the configured logger normalises or stringifies the context (default behaviour for LineFormatter, JsonFormatter via NormalizerFormatter, etc.), sensitive headers such as Cookie (session identifier), Authorization and any custom auth header are written to the log stream in clear text.

Applications that forward logs to centralised platforms (ELK, Splunk, Datadog and similar) are particularly exposed: log access is typically broader than application access, which can allow log readers to hijack authenticated sessions.

Affected versions

Every release prior to 5.3.4 is affected.

Patches

The fix removes the full Request object from the log context and keeps only non-sensitive fields (request path, method, firewall name, user identifier). It is shipped in 5.3.4. Older branches will not receive a backport; users on those branches should upgrade to 5.3.4+ or apply one of the workarounds below.

Workarounds

Until the upgrade is applied, projects can:

  1. Raise the minimum log level for the WebAuthn authenticator above INFO so these two log records are not emitted in production.
  2. Configure their Monolog processor/formatter to strip the request key from the context of these records before they are written.

Credit

Reported by Kay Joosten (Dawn Technology), maintainer of Stepup-Webauthn.

Record
GHSA-q683-8468-r6h6
CVSS 4.0
6.6 MediumCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
Weakness
CWE-200, CWE-532
Updated
2026-11-02

History

History
RecordedChangedSources
first indexedGitHub Advisories, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

References

This page doesn't list everything

Left out here: 70 versions. The JSON record has them.

MoveEnter Open