EEF-CVE-2026-86522 CVE-2026-86522 GHSA-wg7g-r393-vr3g

Log injection via an unescaped password reset identity in AshAuthentication

Not rated yet Hex

Severity: 0.0 / 10; Unknown · CVSS 4.0
Exploit chance (EPSS): 0.74%; Chance of exploitation in the next 30 days. Higher than 54.50% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-117 Improper Output Neutralization for Logs
Fix: 5.0.0-rc.14; Upgrade ash_authentication to this version or later

Description

Summary

Improper Output Neutralization for Logs vulnerability in team-alembic AshAuthentication allows an unauthenticated attacker to forge application log entries by submitting a password reset identity containing newlines or control characters.

AshAuthentication.Strategy.Password.RequestPasswordReset.run/3 interpolates the identity argument, the email or username taken straight from the reset request, into its Logger.warning/1 heredocs without escaping, truncating or type-restricting it. The resource logged beside it is passed through inspect/1, which would have neutralized the value. A newline in the identity therefore ends the log record, and everything after it is written as a line of its own, so an attacker chooses the severity tag and the content of entries that appear to have come from the application.

This issue affects ash_authentication: from 4.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.

Affected versions

Hex

Package	Vulnerable	Fixed in
ash_authentication	`>= 4.2.0, < 4.15.0` `>= 5.0.0-rc.0, < 5.0.0-rc.14`	`4.15.0` `5.0.0-rc.14`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

ash_authentication Hex → `5.0.0-rc.14`

mix

{:ash_authentication, "~> 5.0.0-rc.14"} # then: mix deps.update ash_authentication

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N

Attack vector: Network
Attack complexity: Low
Attack requirements: Present
Privileges required: None
User interaction: None
Confidentiality (vulnerable system): None
Integrity (vulnerable system): Low
Availability (vulnerable system): None
Confidentiality (subsequent systems): None
Integrity (subsequent systems): Low
Availability (subsequent systems): None

Weakness

CWE-117: Improper Output Neutralization for Logs

The product constructs a log message from external input, but it does not neutralize or incorrectly neutralizes special elements when the message is written to a log file.

How to prevent it

Implementation: 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.
Implementation: Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.
Implementation: 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.

References

Advisories

github.com/team-alembic/ash_authentication/security/advisories/GHSA-wg7g-r393-vr3g

Fixes and patches

Packages

hex.pm/packages/ash_authentication

Timeline

Sep 17, 2026 Published
Sep 18, 2026 Last updated by the source
Nov 1, 2026 Latest EPSS score

Advisory	Severity	Why it's related
EEF-CVE-2026-86688 Session id is not renewed on authentication in ash_authentication, allowing session fixation	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-76949 Remember-me sign-in guard reads a session key that is never written in ash_authentication, allowing session replacement	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-91039 dynamic_oidc identities are not namespaced by connection in ash_authentication, allowing cross-connection account takeover	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-88952 OAuth2 sign-in attached to an existing account without an email comparison in AshAuthentication	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-85500 `require_confirmed_with` is not enforced on the action and fails open on an unreadable attribute in AshAuthentication	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-86533 Revoked session accepted because the session jti is never checked in AshAuthentication and AshAuthentication Phoenix	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-81632 Single-use sign-in token placed in a redirect query string in AshAuthenticationPhoenix	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-80218 Sign-in token minted for one resource accepted by another in AshAuthentication	Not rated yet	Also affects ash_authentication

Credits: James Harton, Jonatan Männchen / EEF, Peter Ullrich

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor