OpenShift oauth-proxy lets you impersonate any user with one header trick

The OpenShift oauth-proxy strips dash-style forwarded headers (X-Forwarded-User) but ignores the underscore variant (X_Forwarded_User). WSGI and PHP backends treat both as the same variable. An authenticated, low-privilege user can smuggle a forged identity header that the upstream app trusts as the real authenticated user, letting them impersonate any account the app knows about.

Affected estate

Anyone running openshift/oauth-proxy in front of WSGI (Python/Django/Flask) or PHP applications

How to check

Check the oauth-proxy container image version in your deployments: `oc get pods -o jsonpath='{..image}' | tr ' ' '\n' | grep oauth-proxy`. Test by sending a request with an X_Forwarded_User header and confirming whether the upstream app honors it.

Included because

CVSS 8.5; authenticated but low-complexity; identity spoofing in a common proxy pattern

Action

Upgrade the oauth-proxy image to the patched release. Add header-stripping rules in your ingress or app config to reject underscore-variant forwarded headers.

Why it matters

An authenticated attacker can impersonate other users, potentially gaining admin access to the upstream application without any special privileges.

Source

Red Hat advisory

An out-of-bounds write in GNU binutils' DLX ELF backend lets a crafted ELF file achieve arbitrary code execution when you run objdump, readelf, strip, nm, objcopy, or ld against it. Researchers have demonstrated full code execution via a glibc FILE structure overwrite. The catch: your binutils build needs the DLX backend enabled, which typically happens when built with --enable-targets=all.

Affected estate

Anyone running GNU binutils built with --enable-targets=all, especially CI/CD pipelines, malware analysis sandboxes, and package build systems that process untrusted binaries

How to check

Run `objdump --info | grep -i dlx` to see if the DLX backend is present. Check `objdump --version` or your package manager for the installed version.

Included because

CVSS 7.8; code execution demonstrated; affects common developer and build tooling

Action

Upgrade binutils to the patched release from your distro or upstream. If you compile from source, consider building without --enable-targets=all to exclude DLX.

Why it matters

Arbitrary code execution from processing a malicious file is a serious risk in CI/CD and analysis environments where untrusted binaries are routine.

PhpSpreadsheet's WEBSERVICE() function checks URLs against a domain whitelist before fetching, but PHP's HTTP stream wrapper follows redirects automatically without re-checking the target. An attacker who uploads a crafted XLSX file can bounce through a whitelisted domain to reach internal services, cloud metadata endpoints (169.254.169.254), or arbitrary internal IPs. The response body (up to 32,767 bytes) comes back as a cell value, giving the attacker full read SSRF.

Affected estate

PHP developers and ops teams running applications that accept XLSX uploads and use PhpSpreadsheet's getCalculatedValue() with a domain whitelist configured

How to check

Run `composer show phpoffice/phpspreadsheet` in your project directory to check the installed version. Search code for calls to getCalculatedValue() and setDomainWhiteList().

Included because

CVSS 7.7; SSRF via file upload; cloud credential theft risk; common library in PHP apps

Action

Run `composer update phpoffice/phpspreadsheet` to pull the fixed version for your branch (5.8.1, 3.10.7, 2.4.7, 2.1.18, or 1.30.6).

Why it matters

Full-read SSRF can exfiltrate cloud credentials from metadata services or expose internal APIs, turning a spreadsheet upload into a network-level attack.

Source

GitHub advisory

The sg_inq tool from sg3_utils doesn't sanitize control characters in SCSI name strings when run with --export. A newline embedded in a device-supplied name can inject arbitrary key-value pairs into the udev device database. An attacker who can present a crafted SCSI device (USB, iSCSI, or similar) can trigger arbitrary command execution as root when the device is disconnected. This requires the attacker to physically connect or otherwise present a malicious SCSI device to the target system.

Affected estate

Linux sysadmins running sg3_utils where udev rules invoke sg_inq --export, particularly systems that accept external SCSI devices (USB storage, iSCSI targets, or shared SAN environments)

How to check

Run `sg_inq --version` to check if sg3_utils is installed. Search udev rules for sg_inq references: `grep -r sg_inq /etc/udev/rules.d/ /lib/udev/rules.d/`.

Included because

CVSS 7.6; root code execution; requires physical or network device access, which limits but does not eliminate the threat

Action

Apply the patched sg3_utils package from your distro. Review and harden udev rules to limit which device events trigger sg_inq --export.

Why it matters

A crafted SCSI device can achieve root-level command execution via udev property injection, which is especially concerning for systems that accept removable or network-attached storage.