CWE-614

Setting a nameless cookie with an equals sign in the value shadowed other cookies. Even if the nameless cookie was set over HTTP and the shadowed cookie included the `Secure` attribute. This vulnerability was fixed in Firefox 141, Firefox ESR 140.1, Thunderbird 141, and Thunderbird 140.1.

Boruta is a standalone authorization server that aims to implement OAuth 2.0 and Openid Connect up to decentralized identity specifications. Prior to version 0.9.1, boruta session cookies and the identity “remember me” cookie were set without the Secure attribute. In deployments where users could reach the same Boruta origin over plaintext HTTP, browsers could send these cookies over an unencrypted connection. An attacker able to observe or intercept that network traffic could recover a valid session or remember-me cookie and reuse it to impersonate the affected user. Affected components include boruta_web, boruta_identity, and boruta_admin. The affected cookies include the shared session cookie, defaulting to _boruta_web_key, and the identity remember-me cookie, defaulting to `_boruta_identity_web_user_remember_me`. The issue is fixed in commit 18691c655164635066aa113003a3cd87f6ed11cd, released as part of version 0.9.1. The patch sets `secure: true` and `same_site: "Lax"` on configured session cookies for boruta_web, boruta_identity, and boruta_admin, and sets `secure: true` on the identity remember-me cookie. Until upgrading to a release containing the fix: terminate or reject plaintext HTTP before requests reach Boruta; enforce HTTPS-only access at the reverse proxy or load balancer; enable HSTS for Boruta domains; if cookie exposure is suspected, rotate SECRET_KEY_BASE and BORUTA_SESSION_COOKIE_SIGNING_SALT, then require users to authenticate again. Upgrade to a version containing commit 18691c655164635066aa113003a3cd87f6ed11cd, or apply the patch manually. After deploying the fix, verify that Boruta session and remember-me cookies include the Secure attribute in browser developer tools or with an HTTP response inspection tool.

HAX CMS helps manage microsite universe with PHP or NodeJs backends. Starting in version 25.0.0 and prior to version 26.0.0, the haxcms_refresh_token cookie is set without the Secure flag. This allows it to be transmitted over unencrypted HTTP, making it vulnerable to theft via packet sniffing on the network. Version 26.0.0 fixes the issue.

This vulnerability exists in Digisol DG-GR6821AC Router due to misconfiguration of both Secure and HttpOnly flags on session cookies associated with the router web interface. A remote attacker could exploit this vulnerability by capturing the session cookies transmitted over an unsecure HTTP connection. Successful exploitation of this vulnerability could allow the attacker to obtain sensitive information from the targeted device.

This vulnerability exists in the CP Plus Router due to insecure handling of cookie flags used within its web interface. A remote attacker could exploit this vulnerability by intercepting data transmissions during an HTTP session on the vulnerable system. Successful exploitation of this vulnerability could allow the attacker to obtain sensitive information and compromise the targeted system.

Misskey is an open source, federated social media platform. Starting in version 12.109.0 and prior to version 2025.2.0-alpha.0, due to a lack of CSRF protection and the lack of proper security attributes in the authentication cookies of Bull's dashboard, some of the APIs of bull-board may be subject to CSRF attacks. There is a risk of this vulnerability being used for attacks with relatively large impact on availability and integrity, such as the ability to add arbitrary jobs. This vulnerability was fixed in 2025.2.0-alpha.0. As a workaround, block all access to the `/queue` directory with a web application firewall (WAF).

Pinpoint through version 3.1.0 contains an insecure session management vulnerability that allows attackers to access the pinpointJwt session cookie due to missing HttpOnly and Secure attributes, enabling JavaScript access via document.cookie and cleartext transmission over HTTP. Attackers can exploit stored or reflected cross-site scripting vulnerabilities to exfiltrate the session token or intercept it through network sniffing to perform session hijacking.

In phpipam/phpipam version 1.5.1, the Secure attribute for sensitive cookies in HTTPS sessions is not set. This could cause the user agent to send those cookies in plaintext over an HTTP session, potentially exposing sensitive information. The issue is fixed in version 1.7.0.

Session Hijacking vulnerability in Hitachi Ops Center Analyzer.This issue affects Hitachi Ops Center Analyzer: from 10.0.0-00 before 11.0.1-00.

Sensitive Cookie in HTTPS Session Without 'Secure' Attribute vulnerability in Johnson Controls System Configuration Tool (SCT) version 14 prior to 14.2.3 and version 15 prior to 15.0.3 could allow access to the cookie.

Sensitive Cookie in HTTPS Session Without 'Secure' Attribute in GitHub repository thorsten/phpmyfaq prior to 3.1.9.

Sensitive Cookie in HTTPS Session Without 'Secure' Attribute in GitHub repository ikus060/rdiffweb prior to 2.4.2.

Within the Service Desk module of the ITarian platform (SAAS and on-premise), a remote attacker can obtain sensitive information, caused by the failure to set the HTTP Only flag. A remote attacker could exploit this vulnerability to gain access to the management interface by using this vulnerability in combination with a successful Cross-Site Scripting attack on a user.

Cookie without HTTPONLY flag set. NUMBER cookie(s) was set without Secure or HTTPOnly flags. The images show the cookie with the missing flag. (WebUI)

A cookie security configuration vulnerability in Kentico Xperience allows attackers to bypass SSL requirements when setting administration cookies via web.config. The vulnerability affects .NET Framework projects by incorrectly handling the 'requireSSL' attribute, potentially compromising session security and authentication state.

This vulnerability exists in SyroTech SY-GPON-1110-WDONT Router due to missing secure flag for the session cookies associated with the router's web management interface. An attacker with remote access could exploit this by intercepting transmission within an HTTP session on the vulnerable system. Successful exploitation of this vulnerability could allow the attacker to capture cookies and compromise the targeted system.

A vulnerability in OTRS Application Server and reverse proxy settings allows session hijacking due to missing attributes for sensitive cookie settings in HTTPS sessions. This issue affects: * OTRS 7.0.X * OTRS 8.0.X * OTRS 2023.X * OTRS 2024.X

A vulnerability has been identified in SINEC Traffic Analyzer (6GK8822-1BG01-0BA0) (All versions < V1.2). The affected web server, after a successful login, sets the session cookie on the browser, without applying any security attributes (such as “Secure”, “HttpOnly”, or “SameSite”).

LedgerSMB does not set the 'Secure' attribute on the session authorization cookie when the client uses HTTPS and the LedgerSMB server is behind a reverse proxy. By tricking a user to use an unencrypted connection (HTTP), an attacker may be able to obtain the authentication data by capturing network traffic. LedgerSMB 1.8 and newer switched from Basic authentication to using cookie authentication with encrypted cookies. Although an attacker can't access the information inside the cookie, nor the password of the user, possession of the cookie is enough to access the application as the user from which the cookie has been obtained. In order for the attacker to obtain the cookie, first of all the server must be configured to respond to unencrypted requests, the attacker must be suitably positioned to eavesdrop on the network traffic between the client and the server *and* the user must be tricked into using unencrypted HTTP traffic. Proper audit control and separation of duties limit Integrity impact of the attack vector. Users of LedgerSMB 1.8 are urged to upgrade to known-fixed versions. Users of LedgerSMB 1.7 or 1.9 are unaffected by this vulnerability and don't need to take action. As a workaround, users may configure their Apache or Nginx reverse proxy to add the Secure attribute at the network boundary instead of relying on LedgerSMB. For Apache, please refer to the 'Header always edit' configuration command in the mod_headers module. For Nginx, please refer to the 'proxy_cookie_flags' configuration command.

A Missing Secure Attribute in Encrypted Session (SSL) Cookie vulnerability in HCL AION.This issue affects AION: 2.0.