Monthly
Session hijacking in the VideoWhisper Broadcast Live Video WordPress plugin (up to version 7.3.2) is enabled by a session fixation flaw (CWE-384), allowing remote attackers to take over authenticated sessions, but only if a victim logs in while an attacker-controlled session ID is active (UI:R per independent assessment). No public exploit code exists and no active exploitation is confirmed (not in CISA KEV). The published CVSS 7.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L) overstates the required user interaction and availability impact; the assessed vector is AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N.
Authentication bypass in IBM WebSphere Application Server - Liberty (17.0.0.3 through 26.0.0.10) allows remote, unauthenticated attackers to subvert the SAML 2.0 web single sign-on flow when the samlWeb-2.0 feature is explicitly enabled, resulting in a session fixation condition that yields high confidentiality and integrity impact with no availability impact (CVSS 3.1 base 9.1, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). Because samlWeb-2.0 is an opt-in Liberty feature rather than a default, only deployments that have configured SAML SSO are in scope; in practice exploitation is most credible when a legitimate user subsequently authenticates through an attacker-influenced session, which is a practical limiting factor relative to the raw vector. There is no public exploit identified at time of analysis, no confirmed active exploitation (no CISA KEV listing), and no EPSS score was supplied with the available intelligence.
Session fixation in Omnispace Agora Project before 26.10.0 lets remote, unauthenticated attackers hijack a victim's authenticated session by planting a known session identifier in the victim's browser and waiting for them to log in, because the application does not regenerate the session ID after successful authentication. Exploitation hinges on victim interaction - the target must follow attacker-supplied content that sets a chosen identifier and then actively authenticate to that same session (CVSS UI:A), which is the primary factor limiting real-world abuse. No public exploit code has been identified and the flaw is not confirmed as actively exploited (CISA KEV), and the vendor has shipped 26.10.0 as the fixed release.
Session fixation and cross-user session reuse in the Apache Jackrabbit WebDAV server lets remote attackers ride on a cached authenticated session, yielding high confidentiality and integrity impact with no credential check performed. The flaw affects Jackrabbit 2.20.0 through 2.20.17, 2.22.0 through 2.22.4, and 2.23.0 through 2.23.5, and is triggered whenever a request carries a Lock-Token, TransactionId, SubscriptionId, or If-header token value that matches a token bound to a session already held in the server's authenticated session cache. Per the vendor CVSS 4.0 vector the attack is network-reachable, requires no privileges (PR:N) and no user interaction (UI:N), with the practical limiting factor being that the attacker must obtain or guess a token that currently maps to a live cached session; no public exploit code has been identified at time of analysis, and the product does not confirm active exploitation.
Session fixation in YesWiki before 4.6.7 allows an attacker who can set or learn a victim's pre-authentication YesWiki-* session cookie to reuse that same session after the victim logs in, gaining access to private content and performing actions with the victim's privileges. The root cause is CWE-384: the AuthController login logic authenticates the user without regenerating the PHP session ID, so the pre-login identifier stays valid after authentication. Exploitation is conditional rather than trivial - it requires the attacker to first control the cookie and the victim to subsequently complete a login (CVSS 4.0 7.6 with AC:H/AT:P; independently assessed as CVSS 3.1 AV:N/AC:H/PR:N/UI:R, C:H/I:H/A:N), and no public exploit code has been identified at time of analysis. The vendor has released 4.6.7, which regenerates the session ID on login and removes the condition.
Session hijacking in self-hosted Zammad 6.3.0 through 6.5.4 allows remote, unauthenticated attackers to take over a legitimate user's active session and escalate to remote code execution running with the privileges of the 'zammad' service account. Exploitation requires passive user interaction (CVSS UI:P) - a logged-in agent or admin must load attacker-influenced content - but no prior credentials or privileges (PR:N), so the practical barrier is the narrow vulnerable version window rather than authentication. The same defect exists in Zammad 7.0.0-7.1.3 but is not exploitable there due to environmental conditions; the reporter's CVSS v4.0 base of 9.4 carries an E:A (Attacked) exploit-maturity metric, though no CISA KEV entry or confirmed public exploit code appears in the supplied data, so no public exploit is confirmed at time of analysis.
Session fixation (CWE-384) in Toptech Systems TMS7 and TopHat terminal management platforms allows an attacker to seed a chosen session identifier into a victim's browser/client and then reuse that same identifier after the victim logs in, effectively hijacking the authenticated session and gaining the victim's privileges on the fuel-terminal management application. The reported severity is CVSS 7.5 (CVSS v4.0), and the independent assessment rates confidentiality and integrity impact as high with high attack complexity, because success requires both successful session-ID seeding and the victim subsequently authenticating with that identifier. No public exploit code has been identified and the flaw is not listed as confirmed actively exploited (CISA KEV) at time of analysis, though ICS-CERT has published an advisory (ICSA-26-272-02) indicating OT/ICS relevance.
Session fixation in the HTTP management interface of Apache Qpid Broker-J through 10.1.0 lets remote, unauthenticated attackers hijack an administrator's authenticated management session by reusing a session identifier that is retained across successful authentication, yielding full confidentiality, integrity, and availability impact (C:H/I:H/A:H) over the broker's management functions. Exploitation requires the HTTP management interface to be reachable by the attacker and, critically, requires a legitimate management user - typically an administrator - to authenticate using a session identifier the attacker has planted, fixed, or otherwise obtained before login, so the assessed vector is AV:N/AC:H/PR:N/UI:R rather than the NVD-published 9.8 CRITICAL (AC:L/UI:N), which is inconsistent with the session-fixation class. There is no public exploit identified at time of analysis, and brokers are only exposed where management access is not otherwise restricted; upgrading to 10.1.1 addresses the flaw.
Session fixation in the Elixir/Phoenix authentication library ash_authentication (0.2.0 before 4.15.0, and 5.0.0-rc.0 before 5.0.0-rc.14) allows an attacker who has pre-planted a session identifier in a victim's browser to ride that identifier into the victim's authenticated session. AshAuthentication.Plug.Helpers.store_in_session/2 writes the authenticated subject into the existing session with Plug.Conn.put_session/3 and never calls Plug.Conn.configure_session(renew: true), so the identifier the visitor arrived with survives into their logged-in session through every authentication path, including the default success/4, the mix ash_authentication_phoenix.install AuthController, and remember-me auto-login; logout does not close the window because clear_session/2 ends with Plug.Conn.clear_session/1, which wipes contents but leaves the identifier intact, so a planted identifier survives a logout-then-login cycle. Exploitation is conditional rather than universal: it requires a server-side session store where a rotatable identifier exists (deployments on Phoenix's default signed-cookie session store are largely unaffected, as there is no identifier to fixate), a means of planting the session cookie in the victim's browser, and victim interaction to sign in. No public exploit was identified at time of analysis, although the upstream fix commits and their accompanying regression tests are public.
Session fixation in the default security configuration of Opencast prior to 19.7 and 20.2 lets an unauthenticated attacker who can deliver a crafted link to a victim hijack that victim's authenticated session. Because the shipped etc/security/mh_default_org.xml accepts a client-supplied JSESSIONID via the ;jsessionid= URL path parameter and does not regenerate the identifier at login, an attacker who knows the fixated value can reuse it once the victim authenticates - exposing the victim's data and actions, and escalating to full administrative account takeover when the victim is an administrator. Exploitation requires user interaction (the victim must open the link while holding no active Opencast session cookie and then log in), and no public exploit code or confirmed active exploitation was identified at time of analysis.
Session hijacking in the VideoWhisper Broadcast Live Video WordPress plugin (up to version 7.3.2) is enabled by a session fixation flaw (CWE-384), allowing remote attackers to take over authenticated sessions, but only if a victim logs in while an attacker-controlled session ID is active (UI:R per independent assessment). No public exploit code exists and no active exploitation is confirmed (not in CISA KEV). The published CVSS 7.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L) overstates the required user interaction and availability impact; the assessed vector is AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N.
Authentication bypass in IBM WebSphere Application Server - Liberty (17.0.0.3 through 26.0.0.10) allows remote, unauthenticated attackers to subvert the SAML 2.0 web single sign-on flow when the samlWeb-2.0 feature is explicitly enabled, resulting in a session fixation condition that yields high confidentiality and integrity impact with no availability impact (CVSS 3.1 base 9.1, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). Because samlWeb-2.0 is an opt-in Liberty feature rather than a default, only deployments that have configured SAML SSO are in scope; in practice exploitation is most credible when a legitimate user subsequently authenticates through an attacker-influenced session, which is a practical limiting factor relative to the raw vector. There is no public exploit identified at time of analysis, no confirmed active exploitation (no CISA KEV listing), and no EPSS score was supplied with the available intelligence.
Session fixation in Omnispace Agora Project before 26.10.0 lets remote, unauthenticated attackers hijack a victim's authenticated session by planting a known session identifier in the victim's browser and waiting for them to log in, because the application does not regenerate the session ID after successful authentication. Exploitation hinges on victim interaction - the target must follow attacker-supplied content that sets a chosen identifier and then actively authenticate to that same session (CVSS UI:A), which is the primary factor limiting real-world abuse. No public exploit code has been identified and the flaw is not confirmed as actively exploited (CISA KEV), and the vendor has shipped 26.10.0 as the fixed release.
Session fixation and cross-user session reuse in the Apache Jackrabbit WebDAV server lets remote attackers ride on a cached authenticated session, yielding high confidentiality and integrity impact with no credential check performed. The flaw affects Jackrabbit 2.20.0 through 2.20.17, 2.22.0 through 2.22.4, and 2.23.0 through 2.23.5, and is triggered whenever a request carries a Lock-Token, TransactionId, SubscriptionId, or If-header token value that matches a token bound to a session already held in the server's authenticated session cache. Per the vendor CVSS 4.0 vector the attack is network-reachable, requires no privileges (PR:N) and no user interaction (UI:N), with the practical limiting factor being that the attacker must obtain or guess a token that currently maps to a live cached session; no public exploit code has been identified at time of analysis, and the product does not confirm active exploitation.
Session fixation in YesWiki before 4.6.7 allows an attacker who can set or learn a victim's pre-authentication YesWiki-* session cookie to reuse that same session after the victim logs in, gaining access to private content and performing actions with the victim's privileges. The root cause is CWE-384: the AuthController login logic authenticates the user without regenerating the PHP session ID, so the pre-login identifier stays valid after authentication. Exploitation is conditional rather than trivial - it requires the attacker to first control the cookie and the victim to subsequently complete a login (CVSS 4.0 7.6 with AC:H/AT:P; independently assessed as CVSS 3.1 AV:N/AC:H/PR:N/UI:R, C:H/I:H/A:N), and no public exploit code has been identified at time of analysis. The vendor has released 4.6.7, which regenerates the session ID on login and removes the condition.
Session hijacking in self-hosted Zammad 6.3.0 through 6.5.4 allows remote, unauthenticated attackers to take over a legitimate user's active session and escalate to remote code execution running with the privileges of the 'zammad' service account. Exploitation requires passive user interaction (CVSS UI:P) - a logged-in agent or admin must load attacker-influenced content - but no prior credentials or privileges (PR:N), so the practical barrier is the narrow vulnerable version window rather than authentication. The same defect exists in Zammad 7.0.0-7.1.3 but is not exploitable there due to environmental conditions; the reporter's CVSS v4.0 base of 9.4 carries an E:A (Attacked) exploit-maturity metric, though no CISA KEV entry or confirmed public exploit code appears in the supplied data, so no public exploit is confirmed at time of analysis.
Session fixation (CWE-384) in Toptech Systems TMS7 and TopHat terminal management platforms allows an attacker to seed a chosen session identifier into a victim's browser/client and then reuse that same identifier after the victim logs in, effectively hijacking the authenticated session and gaining the victim's privileges on the fuel-terminal management application. The reported severity is CVSS 7.5 (CVSS v4.0), and the independent assessment rates confidentiality and integrity impact as high with high attack complexity, because success requires both successful session-ID seeding and the victim subsequently authenticating with that identifier. No public exploit code has been identified and the flaw is not listed as confirmed actively exploited (CISA KEV) at time of analysis, though ICS-CERT has published an advisory (ICSA-26-272-02) indicating OT/ICS relevance.
Session fixation in the HTTP management interface of Apache Qpid Broker-J through 10.1.0 lets remote, unauthenticated attackers hijack an administrator's authenticated management session by reusing a session identifier that is retained across successful authentication, yielding full confidentiality, integrity, and availability impact (C:H/I:H/A:H) over the broker's management functions. Exploitation requires the HTTP management interface to be reachable by the attacker and, critically, requires a legitimate management user - typically an administrator - to authenticate using a session identifier the attacker has planted, fixed, or otherwise obtained before login, so the assessed vector is AV:N/AC:H/PR:N/UI:R rather than the NVD-published 9.8 CRITICAL (AC:L/UI:N), which is inconsistent with the session-fixation class. There is no public exploit identified at time of analysis, and brokers are only exposed where management access is not otherwise restricted; upgrading to 10.1.1 addresses the flaw.
Session fixation in the Elixir/Phoenix authentication library ash_authentication (0.2.0 before 4.15.0, and 5.0.0-rc.0 before 5.0.0-rc.14) allows an attacker who has pre-planted a session identifier in a victim's browser to ride that identifier into the victim's authenticated session. AshAuthentication.Plug.Helpers.store_in_session/2 writes the authenticated subject into the existing session with Plug.Conn.put_session/3 and never calls Plug.Conn.configure_session(renew: true), so the identifier the visitor arrived with survives into their logged-in session through every authentication path, including the default success/4, the mix ash_authentication_phoenix.install AuthController, and remember-me auto-login; logout does not close the window because clear_session/2 ends with Plug.Conn.clear_session/1, which wipes contents but leaves the identifier intact, so a planted identifier survives a logout-then-login cycle. Exploitation is conditional rather than universal: it requires a server-side session store where a rotatable identifier exists (deployments on Phoenix's default signed-cookie session store are largely unaffected, as there is no identifier to fixate), a means of planting the session cookie in the victim's browser, and victim interaction to sign in. No public exploit was identified at time of analysis, although the upstream fix commits and their accompanying regression tests are public.
Session fixation in the default security configuration of Opencast prior to 19.7 and 20.2 lets an unauthenticated attacker who can deliver a crafted link to a victim hijack that victim's authenticated session. Because the shipped etc/security/mh_default_org.xml accepts a client-supplied JSESSIONID via the ;jsessionid= URL path parameter and does not regenerate the identifier at login, an attacker who knows the fixated value can reuse it once the victim authenticates - exposing the victim's data and actions, and escalating to full administrative account takeover when the victim is an administrator. Exploitation requires user interaction (the victim must open the link while holding no active Opencast session cookie and then log in), and no public exploit code or confirmed active exploitation was identified at time of analysis.