CWE-614

Mautic 2.6.1 and earlier fails to set flags on session cookies

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.

An issue was discovered in Mattermost Server before 3.0.0. It does not ensure that a cookie is used over SSL.

Synology Router Manager (SRM) before 1.2.4-8081 does not set the Secure flag for the session cookie in an HTTPS session, which makes it easier for remote attackers to capture this cookie by intercepting its transmission within an HTTP session.

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.

In Openshift Origin 3 the cookies being set in console have no 'secure', 'HttpOnly' attributes.

Synology DiskStation Manager (DSM) before 6.2.3-25426-2 does not set the Secure flag for the session cookie in an HTTPS session, which makes it easier for remote attackers to capture this cookie by intercepting its transmission within an HTTP session.

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

A vulnerability has been identified in Desigo DXR2 (All versions < V01.21.142.5-22), Desigo PXC3 (All versions < V01.21.142.4-18), Desigo PXC4 (All versions < V02.20.142.10-10884), Desigo PXC5 (All versions < V02.20.142.10-10884). The application, after a successful login, sets the session cookie on the browser via client-side JavaScript code, without applying any security attributes (such as “Secure”, “HttpOnly”, or “SameSite”). Any attempts to browse the application via unencrypted HTTP protocol would lead to the transmission of all his/her session cookies in plaintext through the network. An attacker could then be able to sniff the network and capture sensitive information.

A vulnerability was found in Macaron csrf and classified as problematic. Affected by this issue is some unknown functionality of the file csrf.go. The manipulation of the argument Generate leads to sensitive cookie without secure attribute. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The patch is identified as dadd1711a617000b70e5e408a76531b73187031c. It is recommended to apply a patch to fix this issue. VDB-217058 is the identifier assigned to this vulnerability.

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)

Sensitive Cookie in HTTPS Session Without 'Secure' Attribute vulnerability in (GTA) GoToAppliance of Secomea GateManager could allow an attacker to gain access to sensitive cookies. This issue affects: Secomea GateManager all versions prior to 9.3.

The Secure flag is not set in the SSL Cookie of Kiwi Syslog Server 9.7.2 and previous versions. The Secure attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP, there is a potential for the cookie can be sent in clear text.

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

Sensitive Cookie in HTTPS Session Without 'Secure' Attribute in GitHub repository pyload/pyload prior to 0.5.0b3.dev32.

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

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.

A vulnerability was found in SourceCodester Engineers Online Portal 1.0. It has been declared as problematic. Affected by this vulnerability is an unknown functionality. The manipulation leads to sensitive cookie without secure attribute. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The identifier VDB-250117 was assigned to this vulnerability.

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

Sensitive Cookie in HTTPS Session Without 'Secure' Attribute in GitHub repository usememos/memos prior to 0.9.0.

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.

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.

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.

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

Sensitive Cookie in HTTPS Session Without 'Secure' Attribute in GitHub repository instantsoft/icms2 prior to 2.16.1.

A vulnerability was determined in TwiN gatus 5.36.0. Impacted is the function setSessionCookie of the file security/oidc.go of the component OIDC Session Cookie Handler. Executing a manipulation can lead to sensitive cookie without secure attribute. The attack can be launched remotely. This attack is characterized by high complexity. The exploitability is considered difficult. The reported GitHub issue was closed with the label "not planned".

IBM Sterling Secure Proxy 6.0.3 and 6.1.0 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic. IBM X-Force ID: 269683.

Apache Airflow's `JWTRefreshMiddleware` set the JWT auth cookie without the `Secure` flag, so deployments running the Airflow API server behind an HTTPS-terminating reverse proxy (e.g. nginx / Envoy / a managed load balancer that terminates TLS and forwards plaintext to the API server, the default cloud-native topology) would have the user's session JWT replayed over any cleartext HTTP request to the same host. A network-positioned attacker (Wi-Fi MITM, hostile LAN, captive-portal proxy) could induce a logged-in user's browser to issue an HTTP request to the deployment's hostname and capture the JWT cookie out of that request, then replay it against the authenticated API. Affects deployments where the Airflow API server is reached through a TLS-terminating proxy and the cookie's secure-by-default protection is load-bearing for session integrity. Users are advised to upgrade to `apache-airflow` 3.2.2 or later.

Default configurations of Apache Shiro send sensitive cookies in HTTPS session without 'Secure' attribute. This issue affects Apache Shiro from 1.0 to 2.1.0, and 3.0.0-alpha-1. Users are recommended to upgrade to version 2.1.1, or 3.0.0-alpha-2 or later, which fixes the issue. In the affected versions, Shiro-native session manager, as well as Remember-Me manager sends JSESSIONID and rememberMe cookies without 'secure' attribute by default.

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.

IBM Sterling B2B Integrator Standard Edition 6.0.0.0 through 6.0.3.8 and 6.1.0.0 through 6.1.2.3 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic. IBM X-Force ID: 265559.

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.

Sensitive Cookie in HTTPS Session Without 'Secure' Attribute in GitHub repository it-novum/openitcockpit prior to 4.6.6.

The Secure attribute is missing on multiple cookies provided by the MEAC300-FNADE4. An attacker can trick a user to establish an unencrypted HTTP connection to the server and intercept the request containing the PHPSESSID cookie.

Taipy is an open-source Python library for easy, end-to-end application development for data scientists and machine learning engineers. In affected versions session cookies are served without Secure and HTTPOnly flags. This issue has been addressed in release version 4.0.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

IBM Security QRadar EDR 3.12 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic.

IBM Datacap Navigator 9.1.5, 9.1.6, 9.1.7, 9.1.8, and 9.1.9 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic. IBM X-Force ID: 296001.

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

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.

IBM Concert 1.0 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic.

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 has been identified in PT-G503 Series firmware versions prior to v5.2, where the Secure attribute for sensitive cookies in HTTPS sessions is not set, which could cause the cookie to be transmitted in plaintext over an HTTP session. The vulnerability may lead to security risks, potentially exposing user session data to unauthorized access and manipulation.

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

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.

IBM PowerHA SystemMirror for i 7.4 and 7.5 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic.

Eaton Intelligent Power Protector (IPP) uses an insecure cookie configuration, which could allow a network‑based attacker to intercept the cookie and exploit it through a man‑in‑the‑middle attack. This security issue has been fixed in the latest version of Eaton IPP software which is available on the Eaton download centre.

IBM Jazz for Service Management 1.1.3.0 through 1.1.3.24 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic.

IBM Security Directory Integrator 7.2.0 and IBM Security Verify Directory Integrator 10.0.0 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic.

IBM Security Directory Integrator 7.2.0 and IBM Security Verify Directory Integrator 10.0.0 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic.

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.

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

IBM Datacap 9.1.7, 9.1.8, and 9.1.9 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic.

IBM Jazz for Service Management 1.1.3.0 through 1.1.3.25 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic.

HCL Unica Platform is affected by a Cookie without HTTPOnly Flag Set vulnerability. A malicious agent may be able to induce this event by feeding a user suitable links, either directly or via another web site.

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

IBM Maximo Application Suite 9.1, 9.0, 8.11, and 8.10 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic.

The Secure and SameSite attribute are missing in the GraphicalData web services and WebClient web app of PcVue in version 12.0.0 through 16.3.3 included.

HCL iControl was affected by Missing Cookie Attributes vulnerability. It was observed that the application is missing several critical cookie attributes, including Secure and SameSite. And also path is set to root.

In JetBrains Datalore before 2026.1 session hijacking was possible due to missing secure attribute for cookie settings

HCL BigFix Compliance is affected by a missing secure flag on a cookie. If a secure flag is not set, cookies may be stolen by an attacker using XSS, resulting in unauthorized access or session cookies could be transferred over an unencrypted channel.

`internal/web/session.go` and `internal/web/oidc.go` set `HttpOnly` and `SameSite=Lax` on every cookie but never `Secure`. A single plaintext request to the origin (operator on a LAN, mistyped URL, HTTP→HTTPS not strictly enforced, reverse proxy misconfiguration) discloses the session. ## Affected All released versions up to v0.3.1. ## Impact An attacker who can observe one HTTP request to the origin recovers the session cookie and impersonates the operator for the remainder of its 24h TTL. The OIDC state cookie has a narrower 10-minute window but enables CSRF on the OIDC callback during that window. ## Cookie sites - `internal/web/session.go` — `Login`, `StartAuthenticatedSession`, `CompleteTwoFactor`, `Logout` - `internal/web/oidc.go` — `HandleLogin` (state set), `HandleCallback` (state clear) ## Suggested fix Driven by an explicit `cookie_secure` config option, inferred true when `tls_cert`+`tls_key` are configured and false otherwise. `rate_limit.trust_proxy_header` is deliberately not used as a signal — that flag controls XFF parsing for rate-limit IPs and does not promise the proxy speaks TLS to clients. Operator behind a TLS-terminating proxy sets `cookie_secure: true` explicitly. Logout and OIDC state-clear cookies also pick up matching `HttpOnly` + `SameSite=Lax` so browsers reliably replace the original. ## Reproducer Start `nebula-mgmt` without `tls_cert`/`tls_key` (the documented "behind a reverse proxy" deployment). Hit any login flow over the local listener: ``` curl -i -X POST -d 'username=admin&password=…' http://127.0.0.1:8080/ui/login ``` The `Set-Cookie: nebula_session=…` line will lack `Secure`. A subsequent unencrypted hop reveals the cookie verbatim. ## Operational migration Operators flipping `cookie_secure` on a running deployment should expect a one-time logout: existing browser cookies have the old attribute set and the new delete-cookie won't match.

### Summary The refresh-token cookie was set with `httpOnly: true` but missing both the `secure` flag and the `sameSite` attribute. Over plain HTTP the cookie could be intercepted on the network; without `sameSite`, browsers attached it to cross-site POSTs, enabling CSRF against the token-refresh endpoint. ### Details In `packages/nocodb/src/services/users/helpers.ts`, `setTokenCookie` produced the cookie with only `httpOnly`, an `expires` date, and an optional `domain` from `NC_BASE_HOST_NAME` — no `secure`, no `sameSite`. The refresh endpoint `POST /api/v2/auth/token/refresh` (`auth.controller.ts`) read the cookie unconditionally and returned a new JWT, with no CSRF token. The fix sets `httpOnly: true`, `sameSite: 'lax'`, and conditional `secure: req.ncSiteUrl.startsWith('https')` so the flag is active under HTTPS while still functional on plain-HTTP localhost development. This is distinct from GHSA-x4vh-j75g-268g (refresh-token lifecycle on password reset) — different root cause, different attack vector. ### Impact - Cookie interception on plain HTTP networks (no `secure`). - Cross-site refresh: malicious cross-origin pages could trigger token refresh and, combined with any same-origin XSS or open-redirect on the NocoDB domain, capture the new JWT. - Refresh tokens have multi-day expiry (`NC_REFRESH_TOKEN_EXP_IN_DAYS`), so the exposure window is long. ### Credit This issue was reported by [@ik0z](https://github.com/ik0z).