Keycloak session fixation, a DoS-in-a-packet for 389 DS, and a chroot that does nothing

An attacker can set up a Keycloak auth session ahead of time, then send a victim a crafted link. When the victim clicks it, Keycloak's SSO silently authenticates them into the attacker's pre-built session, letting the attacker hijack the post-login flow. This can lead to full account takeover, including admin accounts, without ever needing the victim's password.

Included because

unauthenticated; internet-facing; session fixation leading to account takeover; CVSS 7.5

Affected estate

All Keycloak instances exposing /login-actions endpoints, including Red Hat SSO deployments.

How to check

Check your Keycloak version via the admin console or `kcadm.sh` and compare against the vendor's fixed version list.

Action

Upgrade Keycloak to the patched version. If you can't patch immediately, restrict public access to /login-actions/restart at your reverse proxy.

Urgency

Patch within 24 hours

Why it matters

A successful exploit gives an attacker full control of any account, including admin accounts, through a single phishing link.

Source

Red Hat Security Advisory

A privilege escalation bug in Firefox and Thunderbird's Security component lets an attacker gain elevated privileges. Details are thin, but Mozilla fixed it in Firefox 151, Firefox ESR 140.11, Thunderbird 151, and Thunderbird 140.11. If you're behind on browser updates, this one closes a real escalation path.

Included because

privilege escalation; widely deployed endpoint software; CVSS 7.3

Affected estate

Firefox versions before 151, Firefox ESR before 140.11, Thunderbird versions before 151, Thunderbird before 140.11.

How to check

Open Help > About Firefox (or Thunderbird) and verify the version number, or query your software inventory tool.

Action

Push Firefox 151+ and Thunderbird 151+ (or their ESR equivalents) through your patch management system.

Urgency

Patch this week

Why it matters

Privilege escalation in a browser can let a compromised tab or email break out of the sandbox.

Source

Mozilla Foundation Security Advisory

When PluginScript's chroot target is set to `/` (the system root), which is the default in many configurations, the chroot call does nothing. That means plugin scripts can execute any binary on the host, like `/bin/bash`, with root privileges. If you run this with the default `repoManagerRoot` or use the `--root` flag, your plugins have full host access.

Included because

local privilege escalation; default config is vulnerable; CVSS 7.8

Affected estate

Systems running PluginScript with repoManagerRoot set to `/` or invoked with `--root`.

How to check

Check your repo manager config for the `repoManagerRoot` value or look for `--root` in your launch scripts and systemd units.

Action

Update to the patched version. As a mitigation, set repoManagerRoot to a dedicated, non-root directory.

Urgency

Patch this week

Why it matters

A no-op chroot means any plugin script runs with full root access to the host filesystem.

Source

NVD

The haveged daemon checks whether a connecting user on its UNIX socket is root, but if the check fails it doesn't actually stop processing the request. Any local unprivileged user can send privileged commands (like MAGIC_CHROOT) to the haveged socket and have them executed. This is a classic "check but don't enforce" bug.

Included because

local privilege escalation; broken access control; CVSS 7.8

Affected estate

Any Linux system running the haveged daemon with the abstract UNIX socket enabled.

How to check

Run `haveged --version` or `rpm -q haveged` / `dpkg -l haveged` to check your installed version.

Action

Update haveged via your package manager and restart the service.

Urgency

Patch this week

Why it matters

Any local user can execute privileged haveged commands, which could be chained for further escalation on shared systems.

Source

NVD