Cloud Foundry Runtime cf-release before 216, UAA before 2.5.2, and Pivotal Cloud Foundry (PCF) Elastic Runtime before 1.7.0 allow attackers to have unspecified impact by leveraging failure to expire password reset links.

Spring Security OAuth, versions 2.3 prior to 2.3.3, 2.2 prior to 2.2.2, 2.1 prior to 2.1.2, 2.0 prior to 2.0.15 and older unsupported versions contains a remote code execution vulnerability. A malicious user or attacker can craft an authorization request to the authorization endpoint that can lead to remote code execution when the resource owner is forwarded to the approval endpoint.

Spring Data Commons, versions prior to 1.13 to 1.13.10, 2.0 to 2.0.5, and older unsupported versions, contain a property binder vulnerability caused by improper neutralization of special elements. An unauthenticated remote malicious user (or attacker) can supply specially crafted request parameters against Spring Data REST backed HTTP resources or using Spring Data's projection-based request payload binding hat can lead to a remote code execution attack.

In Pivotal Spring AMQP versions prior to 1.7.4, 1.6.11, and 1.5.7, an org.springframework.amqp.core.Message may be unsafely deserialized when being converted into a string. A malicious payload could be crafted to exploit this and enable a remote code execution attack.

Malicious PATCH requests submitted to servers using Spring Data REST versions prior to 2.6.9 (Ingalls SR9), versions prior to 3.0.1 (Kay SR1) and Spring Boot versions prior to 1.5.9, 2.0 M6 can use specially crafted JSON data to run arbitrary Java code.

An issue was discovered in Cloud Foundry Foundation cf-release versions prior to v261; UAA release 2.x versions prior to v2.7.4.17, 3.6.x versions prior to v3.6.11, 3.9.x versions prior to v3.9.13, and other versions prior to v4.2.0; and UAA bosh release (uaa-release) 13.x versions prior to v13.15, 24.x versions prior to v24.10, 30.x versions prior to 30.3, and other versions prior to v37. There is privilege escalation (arbitrary password reset) with user invitations.

An issue was discovered in Pivotal PCF Elastic Runtime 1.6.x versions prior to 1.6.60, 1.7.x versions prior to 1.7.41, 1.8.x versions prior to 1.8.23, and 1.9.x versions prior to 1.9.1. Incomplete validation logic in JSON Web Token (JWT) libraries can allow unprivileged attackers to impersonate other users in multiple components included in PCF Elastic Runtime, aka an "Unauthenticated JWT signing algorithm in multiple components" issue.

An issue was discovered in Pivotal RabbitMQ 3.x before 3.5.8 and 3.6.x before 3.6.6 and RabbitMQ for PCF 1.5.x before 1.5.20, 1.6.x before 1.6.12, and 1.7.x before 1.7.7. MQTT (MQ Telemetry Transport) connection authentication with a username/password pair succeeds if an existing username is provided but the password is omitted from the connection request. Connections that use TLS with a client-provided certificate are not affected.

An issue was discovered in Pivotal GemFire for PCF 1.6.x versions prior to 1.6.5 and 1.7.x versions prior to 1.7.1. The gfsh (Geode Shell) endpoint, used by operators and application developers to connect to their cluster, is unauthenticated and publicly accessible. Because HTTPS communications are terminated at the gorouter, communications from the gorouter to GemFire clusters are unencrypted. An attacker could run any command available on gfsh and could cause denial of service, lost confidentiality of data, escalate privileges, or eavesdrop on other communications between the gorouter and the cluster.

The GemFire broker for Cloud Foundry 1.6.x before 1.6.5 and 1.7.x before 1.7.1 has multiple API endpoints which do not require authentication and could be used to gain access to the cluster managed by the broker.

An issue was discovered in Cloud Foundry Foundation routing-release versions prior to 0.142.0 and cf-release versions 203 to 231. Incomplete validation logic in JSON Web Token (JWT) libraries can allow unprivileged attackers to impersonate other users to the routing API, aka an "Unauthenticated JWT signing algorithm in routing" issue.

An issue was discovered in Cloud Foundry Foundation Cloud Foundry release versions prior to v245 and cf-mysql-release versions prior to v31. A command injection vulnerability was discovered in a common script used by many Cloud Foundry components. A malicious user may exploit numerous vectors to execute arbitrary commands on servers running Cloud Foundry.

Pivotal Cloud Foundry (PCF) Ops Manager before 1.6.17 and 1.7.x before 1.7.8, when vCloud or vSphere is used, does not properly enable SSH access for operators, which has unspecified impact and remote attack vectors.

Cloud Foundry Garden-Linux versions prior to v0.333.0 and Elastic Runtime 1.6.x version prior to 1.6.17 contain a flaw in managing container files during Docker image preparation that could be used to delete, corrupt or overwrite host files and directories, including other container filesystems on the host.

Pivotal Cloud Foundry (PCF) Elastic Runtime before 1.6.34 and 1.7.x before 1.7.12 places 169.254.0.0/16 in the all_open Application Security Group, which might allow remote attackers to bypass intended network-connectivity restrictions by leveraging access to the 169.254.169.254 address.

Spring Batch versions 3.0.9, 4.0.1, 4.1.0, and older unsupported versions, were susceptible to XML External Entity Injection (XXE) when receiving XML data from untrusted sources.

Pivotal Apps Manager Release, versions 665.0.x prior to 665.0.28, versions 666.0.x prior to 666.0.21, versions 667.0.x prior to 667.0.7, contain an invitation service that accepts HTTP. A remote unauthenticated user could listen to network traffic and gain access to the authorization credentials used to make the invitation requests.

Cloud Foundry cf-deployment, versions prior to 7.9.0, contain java components that are using an insecure protocol to fetch dependencies when building. A remote unauthenticated malicious attacker could hijack the DNS entry for the dependency, and inject malicious code into the component.

Spring Web Services, versions 2.4.3, 3.0.4, and older unsupported versions of all three projects, were susceptible to XML External Entity Injection (XXE) when receiving XML data from untrusted sources.

In Cloud Controller versions prior to 1.46.0, cf-deployment versions prior to 1.3.0, and cf-release versions prior to 283, Cloud Controller accepts refresh tokens for authentication where access tokens are expected. This exposes a vulnerability where a refresh token that would otherwise be insufficient to obtain an access token, either due to lack of client credentials or revocation, would allow authentication.

This disclosure regards a vulnerability related to UAA refresh tokens and external identity providers.Assuming that an external identity provider is linked to the UAA, a refresh token is issued to a client on behalf of a user from that identity provider, the administrator of the UAA deactivates the identity provider from the UAA. It is expected that the UAA would reject a refresh token during a refresh token grant, but it does not (hence the vulnerability). It will continue to issue access tokens to request presenting such refresh tokens, as if the identity provider was still active. As a result, clients with refresh tokens issued through the deactivated identity provider would still have access to Cloud Foundry resources until their refresh token expires (which defaults to 30 days).

The Pivotal Ops Manager, 2.2.x versions prior to 2.2.23, 2.3.x versions prior to 2.3.16, 2.4.x versions prior to 2.4.11, and 2.5.x versions prior to 2.5.3, contain configuration that circumvents refresh token expiration. A remote authenticated user can gain access to a browser session that was supposed to have expired, and access Ops Manager resources.

In Mahara before 20.04.5, 20.10.3, 21.04.2, and 21.10.0, the account associated with a web services token is vulnerable to being exploited and logged into, resulting in information disclosure (at a minimum) and often escalation of privileges.

Wire-server is the backing server for the open source wire secure messaging application. In affected versions it is possible to trigger email address change of a user with only the short-lived session token in the `Authorization` header. As the short-lived token is only meant as means of authentication by the client for less critical requests to the backend, the ability to change the email address with a short-lived token constitutes a privilege escalation attack. Since the attacker can change the password after setting the email address to one that they control, changing the email address can result in an account takeover by the attacker. Short-lived tokens can be requested from the backend by Wire clients using the long lived tokens, after which the long lived tokens can be stored securely, for example on the devices key chain. The short lived tokens can then be used to authenticate the client towards the backend for frequently performed actions such as sending and receiving messages. While short-lived tokens should not be available to an attacker per-se, they are used more often and in the shape of an HTTP header, increasing the risk of exposure to an attacker relative to the long-lived tokens, which are stored and transmitted in cookies. If you are running an on-prem instance and provision all users with SCIM, you are not affected by this issue (changing email is blocked for SCIM users). SAML single-sign-on is unaffected by this issue, and behaves identically before and after this update. The reason is that the email address used as SAML NameID is stored in a different location in the databse from the one used to contact the user outside wire. Version 2021-08-16 and later provide a new end-point that requires both the long-lived client cookie and `Authorization` header. The old end-point has been removed. If you are running an on-prem instance with at least some of the users invited or provisioned via SAML SSO and you cannot update then you can block `/self/email` on nginz (or in any other proxies or firewalls you may have set up). You don't need to discriminate by verb: `/self/email` only accepts `PUT` and `DELETE`, and `DELETE` is almost never used.

The IceHrm 30.0.0 OS website was found vulnerable to Session Management Issue. A signout from an admin account does not invalidate an admin session that is opened in a different browser.

Dell EMC Streaming Data Platform versions before 1.3 contain an Insufficient Session Expiration Vulnerability. A remote unauthenticated attacker may potentially exploit this vulnerability to reuse old session artifacts to impersonate a legitimate user.

In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)

The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers and enables session hijacking or shadowing, where the most recent connection displaces the legitimate charging station and receives backend commands intended for that station. This vulnerability may allow unauthorized users to authenticate as other users or enable a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.

Tattile Smart+, Vega, and Basic device families firmware versions 1.181.5 and prior implement an authentication token (X-User-Token) with insufficient expiration. An attacker who obtains a valid token (for example via interception, log exposure, or token reuse on a shared system) can continue to authenticate to the management interface until the token is revoked, enabling unauthorized access to device functions and data.

The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers and enables session hijacking or shadowing, where the most recent connection displaces the legitimate charging station and receives backend commands intended for that station. This vulnerability may allow unauthorized users to authenticate as other users or enable a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.

In Talkyard, regular versions v0.2021.20 through v0.2021.33 and dev versions v0.2021.20 through v0.2021.34, are vulnerable to Insufficient Session Expiration. This may allow an attacker to reuse the admin’s still-valid session token even when logged-out, to gain admin privileges, given the attacker is able to obtain that token (via other, hypothetical attacks)

Apostrophe CMS versions prior to 3.3.1 did not invalidate existing login sessions when disabling a user account or changing the password, creating a situation in which a device compromised by a third party could not be locked out by those means. As a mitigation for older releases the user account in question can be archived (3.x) or moved to the trash (2.x and earlier) which does disable the existing session.

An insufficient session expiration vulnerability [CWE- 613] in FortiClientEMS versions 6.4.2 and below, 6.2.8 and below may allow an attacker to reuse the unexpired admin user session IDs to gain admin privileges, should the attacker be able to obtain that session ID (via other, hypothetical attacks)

Shopware is an open source commerce platform based on Symfony Framework and Vue js. The Administration session expiration was set to one week, when an attacker has stolen the session cookie they could use it for a long period of time. In version 6.4.18.1 an automatic logout into the Administration session has been added. As a result the user will be logged out when they are inactive. Users are advised to upgrade. There are no known workarounds for this issue.

Insufficient Session Expiration in GitHub repository firefly-iii/firefly-iii prior to 6.

A vulnerability, which was classified as problematic, was found in SourceCodester Online Graduate Tracer System 1.0. Affected is an unknown function of the file admin/. The manipulation leads to session expiration. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-224994 is the identifier assigned to this vulnerability.

An insufficient session expiration vulnerability in FortiNet's FortiIsolator version 2.0.1 and below may allow an attacker to reuse the unexpired admin user session IDs to gain admin privileges, should the attacker be able to obtain that session ID (via other, hypothetical attacks)

iControl REST in F5 BIG-IP LTM, AAM, AFM, Analytics, APM, ASM, DNS, Link Controller, PEM, and WebSafe 12.0.0 through 12.1.2 and 13.0.0 includes a service to convert authorization BIGIPAuthCookie cookies to X-F5-Auth-Token tokens. This service does not properly re-validate cookies when making that conversion, allowing once-valid but now expired cookies to be converted to valid tokens.

IBM Curam Social Program Management 8.0.0 and 8.0.1 does not invalidate session after logout which could allow an authenticated user to impersonate another user on the system. IBM X-Force ID: 218281.

A Weak Session Management vulnerability in Citadel WebCit through 926 allows unauthenticated remote attackers to hijack recently logged-in users' sessions. NOTE: this was reported to the vendor in a publicly archived "Multiple Security Vulnerabilities in WebCit 926" thread.

Flag Forge is a Capture The Flag (CTF) platform. In versions from 2.2.0 to before 2.3.1, the FlagForge web application improperly handles session invalidation. Authenticated users can continue to access protected endpoints, such as /api/profile, even after logging out. CSRF tokens are also still valid post-logout, which can allow unauthorized actions. This issue has been patched in version 2.3.1.

2N Access Commander version 3.4.2 and prior improperly invalidates session tokens, allowing multiple session cookies to remain active after logout in web application.

An issue was discovered in October through build 471. It reactivates an old session ID (which had been invalid after a logout) once a new login occurs. NOTE: this violates the intended Auth/Manager.php authentication behavior but, admittedly, is only relevant if an old session ID is known to an attacker.

This vulnerability occurs when the system permits multiple simultaneous connections to the backend using the same charging station ID. This can result in unauthorized access, data inconsistency, or potential manipulation of charging sessions. The lack of proper session management and expiration control allows attackers to exploit this weakness by reusing valid charging station IDs to establish multiple sessions concurrently.

File Browser provides a file managing interface within a specified directory and it can be used to upload, delete, preview, rename, and edit files. In version 2.39.0, File Browser’s authentication system issues long-lived JWT tokens that remain valid even after the user logs out. As of time of publication, no known patches exist.

The TeleMessage service through 2025-05-05 implements authentication through a long-lived credential (e.g., not a token with a short expiration time) that can be reused at a later date if discovered by an adversary.

A vulnerability was found in Dígitro NGC Explorer up to 3.44.15 and classified as problematic. This issue affects some unknown processing. The manipulation leads to session expiration. The attack may be initiated remotely. The vendor was contacted early about this disclosure but did not respond in any way.

Insufficient Session Expiration vulnerability in hexpm hexpm/hexpm ('Elixir.Hexpm.Accounts.PasswordReset' module) allows Account Takeover. Password reset tokens generated via the "Reset your password" flow do not expire. When a user requests a password reset, Hex sends an email containing a reset link with a token. This token remains valid indefinitely until used. There is no time-based expiration enforced. If a user's historical emails are exposed through a data breach (e.g., a leaked mailbox archive), any unused password reset email contained in that dataset could be used by an attacker to reset the victim's password. The attacker does not need current access to the victim's email account, only access to a previously leaked copy of the reset email. This vulnerability is associated with program files lib/hexpm/accounts/password_reset.ex and program routines 'Elixir.Hexpm.Accounts.PasswordReset':can_reset?/3. This issue affects hexpm: from 617e44c71f1dd9043870205f371d375c5c4d886d before bb0e42091995945deef10556f58d046a52eb7884.

A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions < V4.1 Update 3), SIMATIC PCS neo V5.0 (All versions < V5.0 Update 1). Affected products do not correctly invalidate user sessions upon user logout. This could allow a remote unauthenticated attacker, who has obtained the session token by other means, to re-use a legitimate user's session even after logout.

Not properly invalidated session vulnerability in Graylog Web Interface, version 2.2.3, due to incorrect management of session invalidation after new logins. The application generates a new 'sessionId' each time a user authenticates, but does not invalidate previously issued session identifiers, which remain valid even after multiple consecutive logins by the same user. As a result, a stolen or leaked 'sessionId' can continue to be used to authenticate valid requests. Exploiting this vulnerability would allow an attacker with access to the web service/API network (port 9000 or HTTP/S endpoint of the server) to reuse an old session token to gain unauthorized access to the application, interact with the API/web, and compromise the integrity of the affected account.