CVE-2026-113669: 
JavaScript Analyse et atténuation des vulnérabilités

CVE-2026-113669 is a session hijacking vulnerability in ApostropheCMS titled "Cross-domain session token in URL confers session takeover." During cross-host or cross-locale session migration, a single-use bearer session token is placed as a URL query parameter (?aposCrossDomainSessionToken), exposing it to server logs, browser history, and Referer headers. Any client that obtains and redeems this token before its legitimate first use silently adopts the associated user session, including full passport.user credentials. Affected versions are ApostropheCMS (apostrophe npm package) prior to 4.33.0 and @apostrophecms/passport-bridge prior to 1.6.1. It carries a CVSS v4 base score of 5.3 (Medium) (Github Advisory).

The root cause is classified as CWE-598 (Use of GET Request Method With Sensitive Query Strings): the cross-domain session migration logic in packages/apostrophe/modules/@apostrophecms/i18n/index.js (L479–487) and passport-bridge/index.js (L557–593) generates a session token and appends it to a redirect URL rather than transmitting it via a secure channel. The acceptCrossDomainSessionToken handler (L258–298) reads the ?aposCrossDomainSessionToken query parameter, performs an Object.assign of the stored session (including passport.user) onto req.session, and then nulls the MongoDB cache entry — making it nominally single-use. However, the token was generated with a non-cryptographic ID generator, remained valid for up to one hour, and could be redeemed on any hostname, creating a meaningful interception window. The middleware handling token redemption is registered globally for every URL (Github Advisory, Security Commit).

Successful exploitation results in full session hijacking and account takeover of the migrated user, granting the attacker all privileges associated with that account — including administrative access if an admin session token is intercepted. Because the token appears in URLs, it is realistically exposed through server and proxy access logs, browser history, and the HTTP Referer header (particularly relevant in the cross-host use case). Confidentiality, integrity, and availability of the CMS and its managed content are all at risk, as an attacker with an adopted admin session can read, modify, or delete any content (Github Advisory).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at the time of disclosure (Github Advisory). The EPSS score is 0.0, reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to obtain an unconsumed token — feasible via log access, network interception, or Referer header leakage — and redeem it before the legitimate user does, which is a narrow but realistic window given the original one-hour token validity.

1. Reconnaissance: Identify an ApostropheCMS instance running a version prior to 4.33.0 that uses cross-host or cross-locale session migration (multi-locale or multi-domain deployments using @apostrophecms/passport-bridge).
2. Token acquisition: Obtain the aposCrossDomainSessionToken value from one of its exposure vectors — server/proxy/CDN access logs, browser history on a shared machine, or the HTTP Referer header captured when a user navigates from the source host to a different destination host.
3. Token redemption: Before the legitimate user completes their redirect, send an HTTP GET request to the target host with the stolen token as a query parameter:

   curl -c atk.cookies "http://target-host/?aposCrossDomainSessionToken=<STOLEN_TOKEN>"

   The server responds with a 302 redirect and sets a session cookie (vulnlab.sid or equivalent) on the attacker's client.
4. Session use: Use the newly acquired session cookie to access privileged resources:

   curl -b atk.cookies "http://target-host/api/v1/@apostrophecms/page/<page-id>:en:draft"

   The server returns a 200 response with the content of the adopted session's user, including any admin-only data.
5. Token consumed: The cache entry is nulled after first redemption, but if the attacker redeems it first, the legitimate user's redirect fails harmlessly while the attacker holds the session (Github Advisory).

• Network: HTTP GET requests to any application URL containing the query parameter ?aposCrossDomainSessionToken= from an IP address that is not the expected user's client; requests to the token redemption endpoint followed immediately by API calls from a previously unauthenticated client.
• Logs: Web server or proxy access logs showing the aposCrossDomainSessionToken parameter in request URLs — particularly from unexpected source IPs or user agents; log entries showing a 302 redirect on token redemption followed by privileged API access from a new session ID.
• Application/Session: A session cookie (connect.sid, vulnlab.sid, or equivalent) appearing on a client that never performed a login flow; the MongoDB cache entry for @apostrophecms/i18n:cross-domain-sessions:<token> showing {"value":null} (consumed) without a corresponding successful user redirect in application logs.
• Referer Header Leakage: Outbound HTTP requests from the CMS server or client browsers to third-party hosts carrying a Referer header that includes aposCrossDomainSessionToken in the URL (Github Advisory).

Upgrade ApostropheCMS (apostrophe npm package) to version 4.33.0 or later, and @apostrophecms/passport-bridge to version 1.6.1 or later (Github Advisory, Release Notes). The fix hardens the token mechanism: tokens are now 256-bit cryptographically secure values, expire after 60 seconds (down from one hour), are bound to the specific hostname they were minted for, and are consumed atomically. The redirect that strips the token from the URL is now sent with Referrer-Policy: no-referrer and Cache-Control: no-store headers. As an interim measure before patching, review and restrict access to server/proxy access logs, and invalidate any single-use session tokens that may have been exposed (Security Commit).

The vulnerability was reported by security researcher Anisetti Chaitanya Eshwar Prasad and disclosed by ApostropheCMS maintainer boutell via a GitHub Security Advisory on October 2, 2026, published to the GitHub Advisory Database on October 20, 2026 (Github Advisory). The fix was bundled with a large batch of security advisories addressed in the same release (apostrophe@4.33.0), covering over a dozen separate vulnerabilities across the ApostropheCMS ecosystem (Security Commit). No significant broader media coverage or notable community commentary beyond the official advisory has been identified.