CVE-2026-75757: AshAdmin cookie reader matches names by substring, enabling actor/session shadowing from a sibling subdomain
Reliance on Cookies without Validation and Integrity Checking vulnerability in ash-project ashadmin lets an attacker who controls a sibling subdomain rebind an admin's session to a different actor, tenant, or authorization mode.
AshAdmin's client JavaScript read its state cookies (tenant, actorresource, actorprimarykey, actoraction, actordomain, actorauthorizing, actorpaused) by matching the cookie name with an unanchored regular expression (new RegExp(name + "=([^;]+)")) against the whole document.cookie. Any cookie whose name merely ends with the requested name therefore matches, and whichever is serialized first wins. Because cookies are shared across a registrable domain, a compromised sibling subdomain can set a shadowing cookie (for example xactorauthorizing) with Domain=.example.com that flows unvalidated into the admin's LiveSocket connect params. The fix matches cookie names by exact equality.
This issue affects ashadmin: from 0.9.1 before 1.3.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ash_adminto a version that resolves this vulnerability.Fixed in 1.3.1 - Configuration
Update ash_admin to change cookie lookup logic so cookie names are matched by exact equality rather than substring/unanchored regex (previously used new RegExp(name + "=([^;]+)") against document.cookie).
ash-project ash_admin client JavaScript cookie reader cookie name matching = exact equality (no substring/unanchored regex)
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Deployments using ash_admin versions from 0.9.1 before 1.3.1 are affected when an attacker can control or compromise a sibling subdomain under the same registrable domain. The sibling subdomain must be able to set a Domain-scoped cookie, such as one scoped to .example.com, that is sent to the admin application.
What does an attacker need to exploit this issue?
The attacker needs control of a sibling subdomain and the ability to cause a shadowing cookie with a name ending in one of AshAdmin's state-cookie names to be set. Cookie ordering also matters, because the first matching cookie serialized in document.cookie is used.
What is the impact of a successful shadowing attack?
A malicious sibling-subdomain cookie can be accepted as AshAdmin state and passed in the admin LiveSocket connection parameters. This can rebind an administrator's session to a different actor, tenant, or authorization mode.
What should be done if updating is not immediately possible?
Restrict control of sibling subdomains and prevent untrusted or compromised subdomains from setting cookies scoped to the parent registrable domain. Review Domain-scoped cookies for names that end with AshAdmin state-cookie names, including tenant, actor_resource, actor_primary_key, actor_action, actor_domain, actor_authorizing, and actor_paused.
How can I determine whether the fix is present?
The corrected behavior matches cookie names by exact equality rather than using an unanchored regular-expression match against document.cookie. ash_admin version 1.3.1 and later is outside the affected range.