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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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 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 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).

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.

An insufficient JWT validation vulnerability was found in Kiali versions 0.4.0 to 1.15.0 and was fixed in Kiali version 1.15.1, wherein a remote attacker could abuse this flaw by stealing a valid JWT cookie and using that to spoof a user session, possibly gaining privileges to view and alter the Istio configuration.

A token-reuse vulnerability in ZKTeco FaceDepot 7B 1.0.213 and ZKBiosecurity Server 1.0.0_20190723 allows an attacker to create arbitrary new users, elevate users to administrators, delete users, and download user faces from the database.

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.

In JetBrains TeamCity before 2024.07 access tokens could continue working after deletion or expiration

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.

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.

IBM WebSphere Application Server Liberty 23.0.0.9 through 23.0.0.10 could provide weaker than expected security due to improper resource expiration handling. IBM X-Force ID: 268775.

xzs-mysql 3.8 is vulnerable to Insufficient Session Expiration, which allows attackers to use the session of a deleted admin to do anything.

Sierra Wireless GX 440 devices with ALEOS firmware 4.3.2 use guessable session tokens, which are in the URL.

In the Samly package before 1.4.0 for Elixir, Samly.State.Store.get_assertion/3 can return an expired session, which interferes with access control because Samly.AuthHandler uses a cached session and does not replace it, even after expiry.

A CWE-614 Insufficient Session Expiration vulnerability exists that could allow an attacker to maintain an unauthorized access over a hijacked session to the charger station web server even after the legitimate user account holder has changed his password. Affected Products: EVlink City EVC1S22P4 / EVC1S7P4 (All versions prior to R8 V3.4.0.2 ), EVlink Parking EVW2 / EVF2 / EVP2PE (All versions prior to R8 V3.4.0.2), and EVlink Smart Wallbox EVB1A (All versions prior to R8 V3.4.0.2)

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)

A flaw was found in the CloudForms account configuration when using VMware. By default, a shared account is used that has privileged access to VMRC (VMWare Remote Console) functions that may not be appropriate for users of CloudForms (and thus this account). An attacker could use this vulnerability to view and make changes to settings in the VMRC and virtual machines controlled by it that they should not have access to.

Insufficient Session Expiration vulnerability in Drupal Persistent Login allows Forceful Browsing.This issue affects Persistent Login: from 0.0.0 before 1.8.0, from 2.0.* before 2.2.2.

Magento versions 2.4.1 (and earlier), 2.4.0-p1 (and earlier) and 2.3.6 (and earlier) do not adequately invalidate user sessions. Successful exploitation could lead to unauthorized access to restricted resources. Access to the admin console is not required for successful exploitation.

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)

Insufficient Session Expiration in GitHub repository thorsten/phpmyfaq prior to 3.2.2.

Insufficient Session Expiration in GitHub repository linkstackorg/linkstack prior to v4.2.9.

Insufficient Session Expiration vulnerability in Apache Airflow Providers FAB. This issue affects Apache Airflow Providers FAB: 1.2.1 (when used with Apache Airflow 2.9.3) and FAB 1.2.0 for all Airflow versions. The FAB provider prevented the user from logging out.   * FAB provider 1.2.1 only affected Airflow 2.9.3 (earlier and later versions of Airflow are not affected) * FAB provider 1.2.0 affected all versions of Airflow. Users who run Apache Airflow 2.9.3 are recommended to upgrade to Apache Airflow Providers FAB version 1.2.2 which fixes the issue. Users who run Any Apache Airflow version and have FAB provider 1.2.0 are recommended to upgrade to Apache Airflow Providers FAB version 1.2.2 which fixes the issue. Also upgrading Apache Airflow to latest version available is recommended. Note: Early version of Airflow reference container images of Airflow 2.9.3 and constraint files contained FAB provider 1.2.1 version, but this is fixed in updated versions of the images.  Users are advised to pull the latest Airflow images or reinstall FAB provider according to the current constraints.

Social media skeleton is an uncompleted/framework social media project implemented using a php, css ,javascript and html. Insufficient session expiration is a web application security vulnerability that occurs when a web application does not properly manage the lifecycle of a user's session. Social media skeleton releases prior to 1.0.5 did not properly limit manage user session lifecycles. This issue has been addressed in version 1.0.5 and users are advised to upgrade. There are no known workarounds for this vulnerability.

In Siren Investigate before 13.2.2, session keys remain active even after logging out.

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.

An insufficient session expiration in Fortinet FortiOS 7.0.0 - 7.0.12 and 7.2.0 - 7.2.4 allows an attacker to execute unauthorized code or commands via reusing the session of a deleted user in the REST API.

Cosmos provides users the ability self-host a home server by acting as a secure gateway to your application, as well as a server manager. Cosmos-server is vulnerable due to to the authorization header used for user login remaining valid and not expiring after log out. This vulnerability allows an attacker to use the token to gain unauthorized access to the application/system even after the user has logged out. This issue has been patched in version 0.13.1.

A vulnerability in Parsec Windows 142-0 and Parsec 'Linux Ubuntu 16.04 LTS Desktop' Build 142-1 allows unauthorized users to maintain access to an account.

DataHub is an open-source metadata platform. In versions of DataHub prior to 0.8.45 Session cookies are only cleared on new sign-in events and not on logout events. Any authentication checks using the `AuthUtils.hasValidSessionCookie()` method could be bypassed by using a cookie from a logged out session, as a result any logged out session cookie may be accepted as valid and therefore lead to an authentication bypass to the system. Users are advised to upgrade. There are no known workarounds for this issue. This vulnerability was discovered and reported by the GitHub Security lab and is tracked as GHSL-2022-083.

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.