There’s another ransomware story this week, but this one comes with a special twist. If you’ve followed this column for long, you’re aware that ransomware has evolved beyond just encrypting files. Perhaps we owe a tiny bit of gratitude to ransomware gangs for convincing everyone that backups are important. The downside to companies getting their backups in order is that these criminals are turning to other means to extort payment from victims. Namely, exfiltrating files and releasing them to the public if the victim doesn’t pay up. And this is the situation in which the Akira ransomware actors claim to have Apache’s OpenOffice project.

There’s just one catch. Akira is threatening to release 23 GB of stolen documents, which include employee information — and the Apache Software Foundation says those documents don’t exist. OpenOffice hasn’t received a demand and can’t find any evidence of a breach. It seems likely that Akira has hit some company, but not part of the Apache Software Foundation. Possibly someone that heavily uses OpenOffice, or even provides some level of support for that application. There is one more wrinkle here.

Since Apache OpenOffice is an open source software project, none of our contributors are paid employees for the project or the foundation…

First off, there are plenty of open source projects that have employee contributors, and it’s quite odd to imply otherwise. But second, for something as important as an office suite, this is a rather startling statement: there are no paid employees working on the OpenOffice code base.

NPM Typosquat Sophistication

There’s another NPM typosquatting campaign, which is barely news at this point. This one is newsworthy because these malicious packages use multiple layers of obfuscation, and lived on NPM for over four months. They use a clever bit of social engineering during package installation, in the form of a fake CAPTCHA prompt. The idea is that it makes the user less suspicious of the package, and also gives a legitimate reason for network access. But in reality, requiring user interaction defeats any automated analysis efforts.

The first layer of obfuscation consists of an eval() call with a bunch of decoder functions and an ugly encoded string. The result from that set of functions is URL-encoded and needed decoding, followed by an XOR with a key value. And finally, the executable function that finally emerges uses switch/case statements and hard-to-read values. It’s just a web to work through.

The payload behavior is boring in comparison, looking for any credentials on the system and uploading them to a remote server. It also checks for interesting browser cookies and passwords in the password manager, and any authentication tokens it can find.

WordPress Plugin Problems

[István Márton] at Wordfence has the story on a pair of WordPress plugins with severe vulnerabilities, effecting a whopping 500,000 sites combined. Up first is AI Engine, with 100,000 installs. This plugin has an unauthenticated URL endpoint that can expose a bearer token, which then allows access to the MCP endpoint, and arbitrary control of users. The good news here is that the plugin is not vulnerable by default, and requires the “No-Auth URL” setting to be configured to be vulnerable.

The other plugin is Post SMTP, with 400,000 installs. It replaces WordPress’s PHP email handling, and one of the features is the ability to view those emails from the logs. The problem was that before 3.6.1, viewing those email logs didn’t require any permissions. At first blush, that may seem like a medium severity problem, but WordPress is often configured to allow for password resets via emailed links, which means instant account takeover. Both issues have been fixed, and releases are available.

React Native CLI and Metro

A combination of the React Native CLI package and the Metro development server exposed React Native developers to a nasty 9.8 CVSS Remote Code Execution (RCE) CVE. The first element of this vulnerability is the fact that when Metro opens ports for hosting development work, it doesn’t bind to localhost, but listens on all interfaces by default.

When a new Reactive Native project is created without using a framework, some boilerplate code is run as part of the initialization. The end result is that /open-url handler is added to the project, and this handler calls open() with an outside string from the URL. It’s not hard to imagine how this can be abused for arbitrary code injection.

KASLR

Let’s talk about address randomization. Specifically, Kernel Address Space Layout Randomization (KASLR). It’s one of the defenses against turning an arbitrary memory write into a working exploit. If an attacker can’t predict where kernel objects will be in memory, twiddling bits is more likely to crash the system than result in code execution. It’s great in theory. The problem is that it doesn’t necessarily exist in reality.

That’s the story from [Seth Jenkins] at Google’s Project Zero, who was looking for ways to crack Pixel phones. It turns out that memory hotplugging is supported by Linux on Android, and that potential hotplug memory needs a lot of room in the linear memory map. So much room that it’s impractical to also randomize that layout. So while we still technically have KASLR protecting the kernel from attacks, there’s a really big gotcha in the form of the linear memory map.

Bits and Bytes

If you want a really deep dive into how BLE works, and how to investigate an existing BLE connection with an SDR, [Clément Ballabriga] from Lexfo has the scoop. It is significantly more complicated than you might expect, particularly since BLE uses frequency hopping, and a wide enough range of frequencies that your SDR almost certainly can’t capture them all at once. That means breaking a tiny part of the signal security, in order to accurately predict the frequency hops.

Cisco’s Unified Contact Center Express (UCCX) has several vulnerabilities that allows an attacker to run code as root. One vulnerability is in handling arbitrary file uploads by the Java Remote Method Invocation system. Another is an authentication bypass that can be exploited by coercing the target system to use a malicious remote server as part of the authentication process. Fixes are available, and so far it doesn’t look like these flaws have been used in the wild.

And finally, there’s the November Android security bulletin, that fixes CVE-2025-48593, a logic error in security updates in apexd.cpp that can lead to escalation of privilege.

I’ve seen this flaw conflated with CVE-2025-38593, a Bluetooth vulnerability recently fixed in the Linux kernel. This is a medium severity race condition in the kernel that can lead to a double-free and a system crash. There doesn’t seem to be a way to turn this into an RCE, as is reflected by its CVSS of 4.7.