Loading story…
A high-severity flaw tracked as CVE-2026-53661 affected Boruta, a standalone OAuth 2.0 and OpenID Connect authorization server, by issuing session cookies and the identity remember me cookie without the Secure attribute. In affected deployments, browsers could send those cookies over plaintext HTTP, creating a risk that attackers monitoring or intercepting traffic could steal valid cookies and hijack authenticated sessions, including administrative sessions. The issue impacted all released versions through 0.9.0 and unreleased builds before commit 18691c655164635066aa113003a3cd87f6ed11cd, with affected components including boruta_web, boruta_identity, and boruta_admin and default cookies such as _boruta_web_key and _boruta_identity_web_user_remember_me.
The project addressed the flaw in commit 18691c655164635066aa113003a3cd87f6ed11cd, which enforces secure cookie handling across Boruta endpoints, adds SameSite=Lax to configured session cookies, and updates the remember-me cookie to require HTTPS transport. The fix was subsequently released in version 0.9.1. Maintainers advised operators to enforce HTTPS-only access, reject plaintext HTTP, enable HSTS, verify that cookies are deployed with the Secure attribute, and rotate secrets such as SECRET_KEY_BASE and BORUTA_SESSION_COOKIE_SIGNING_SALT if cookie exposure is suspected.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
The CVE record for CVE-2026-53661 reported that Boruta's insecure cookie handling issue was fixed in commit 18691c655164635066aa113003a3cd87f6ed11cd and released in version 0.9.1. It described exposure of session and remember-me cookies without the Secure attribute across boruta_web, boruta_identity, and boruta_admin.
A GitHub security advisory disclosed that all released Boruta versions through 0.9.0 set session and remember-me cookies without the Secure attribute, enabling possible session hijacking if traffic was intercepted over HTTP. The advisory stated the fix was available in commit 18691c655164635066aa113003a3cd87f6ed11cd, but that no tagged release yet contained the patch.
A security commit updated BorutaAdminWeb, BorutaIdentityWeb, and BorutaWeb to set the Secure flag and SameSite=Lax on session cookies, and added the Secure flag to the remember-me cookie configuration. This change mitigated the risk of cookies being transmitted over plaintext HTTP.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
3 references tracked. Mallory keeps watching after this page renders.
cvefeed.io
Open sourcegithub.com
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
OpenBao disclosed two high-severity vulnerabilities in its OIDC/JWT authentication flow affecting versions before **2.5.2**, both tied to roles configured with `callback_mode=direct`. **CVE-2026-33757** allows a remote phishing-style attack because direct callback logins do not require user confirmation, letting an attacker initiate authentication and trick a victim into completing it for the attacker's session. Because the callback returns to the API and the attacker can poll for token issuance, successful exploitation can expose secrets and enable unauthorized actions, with the flaw tracked as **CWE-384**. A second issue, **CVE-2026-33758**, allows reflected cross-site scripting through the `error_description` parameter on a failed OIDC authentication page, potentially exposing a victim's Web UI token. OpenBao addressed both flaws in **2.5.2** by adding a mandatory confirmation screen for direct logins and replacing the user-controlled error text with a static message. Organizations using OpenBao were advised to remove roles using `callback_mode=direct` or enforce confirmation at the identity provider for the Client ID used by OpenBao until upgrades are completed.
Jun 29, 2026
Red Hat released security updates for **Red Hat build of Keycloak** to fix a critical account-takeover vulnerability, tracked as `CVE-2026-18963`, in the `keycloak-services` component. The flaw affects the reset-credentials flow and allows an unauthenticated remote attacker to bypass the email verification step during password recovery, reset a victim's password, and take full control of the account. Affected versions include **26.4.x before 26.4.15** and **26.6.x before 26.6.6**, with scanners such as Nessus flagging vulnerable deployments based on reported version information. Red Hat addressed the issue in advisories **RHSA-2026:56523** and **RHSA-2026:56524**, releasing updated packages, container images, and an updated Operator for OpenShift. The advisories also bundle fixes for additional Keycloak security issues, including hidden group metadata disclosure, predictable account-linking hashes that could enable takeover through a malicious OIDC client, rotated client secret leakage via the Admin REST API, and a TOCTOU privilege-escalation bug. Red Hat advised customers to back up installations before upgrading, while **Red Hat JBoss Enterprise Application Platform Expansion Pack** was also listed as affected but did not yet have a vendor patch in the referenced reporting.
Aug 25, 2026
decolua disclosed and fixed **CVE-2026-55500** in 9Router, a high-severity flaw affecting versions earlier than `0.4.80` that left the `/api/settings/database` endpoint insufficiently protected. The issue allowed database export and import operations that could expose stored credentials, API keys, OAuth tokens, and configuration data, while also enabling a complete database overwrite that could hand an attacker control over the application state. The remediation adds re-authentication for database export and import by requiring the current dashboard password, except for requests using a CLI token, and updates the UI to prompt for that password before sensitive operations. The same security patch also introduced an SSRF guard for `/v1/web/fetch` to block requests to localhost, internal hostnames, private IPv4 ranges, and private or loopback IPv6 addresses, addressing a separate server-side request forgery risk referenced alongside the database protection fix.
Jul 10, 2026