Thirteen Root-Level Injection Paths Found in pfSense CE Development Code

Abraxas Labs audited the pfSense Community Edition WebGUI and found 13 new remote code execution paths in the project’s current development branch. We cover which pages and services are involved, what an attacker needs to reach them, and how to tighten management access while Netgate reviews the findings.

What You Need to Know

Every path in the Abraxas Labs report ends with commands running as root. The research covers public GitHub master commit 9363ac5, which identifies itself as pfSense CE 2.9.0-DEVELOPMENT. No CVEs have been assigned, and Netgate hasn’t published an advisory or fixed builds. If your organization delegates limited WebGUI access or runs OpenVPN with RADIUS or certificate authentication, review your exposure now.

What’s Vulnerable

The researchers reported their findings to Netgate. All of them trace back to unsafe input handling in WebGUI pages and service configuration workflows that PHP-FPM executes as root.

The paths cover much of the firewall’s configuration surface:

• Wireless clone data is passed to ifconfig.
• An unvalidated interface name is processed through Assign Interfaces.
• An IPv6 zone identifier is interpolated into a dpinger command.
• Timezone data can be injected into php.ini.
• sshguard settings allow CRLF injection.
• An L2TP RADIUS secret is written into mpd.conf.
• Two separate PPPoE paths affect crontab and mpd.secret.
• A Captive Portal HA host is passed to pfctl.
• Unbound has two configuration injection paths.
• An OpenVPN RADIUS username is evaluated by connect_async.
• An OpenVPN certificate common name is passed into an unquoted su -c command.

Not every path fires right away. Some execute immediately. Others wait for a service restart, the next PHP request, a VPN connection, or a configuration reload.

Why This Matters

The “remote” label overstates things a bit. These findings don’t establish unauthenticated command execution through the WebGUI. Most require an authenticated, limited WebGUI account with access to a specific page. The OpenVPN findings need a RADIUS-authenticated VPN user or a client certificate.

That’s still a real problem. pfSense’s page-level privileges exist to confine delegated users to the functions they need. But the PHP processes behind those pages run as root, so a user trusted with one narrow page can take over the whole firewall. The delayed-execution paths also make attribution harder, because a reboot or routine service reload can separate the malicious input from the command it eventually runs.

How many production systems are affected is still unclear. We haven’t been able to confirm that the tested code matches pfSense CE 2.9.0-RELEASE, because the matching release PHP source isn’t in the public repository. Treat this research as evidence of vulnerable development code. It doesn’t confirm that every issue affects production 2.9.0-RELEASE installations.

What to Do

• Keep the pfSense management interface off the internet, and limit WebGUI access to trusted management networks.
• Review delegated page permissions and remove any limited-user privileges that aren’t strictly needed. Those accounts are the entry point for most of these paths.
• Watch for unexpected changes to these configurations: interface, gateway, PPPoE, L2TP, Captive Portal, Unbound, OpenVPN, sshguard, timezone, and cron.
• Until Netgate publishes an advisory or fixed builds, check your exposure against the specific development commit. Version labels alone can’t confirm or rule out risk.

A CVSS 10 Metabase Flaw Lets Attackers Compromise the Admin Account

Metabase’s password-reset endpoint has a SQL injection flaw that attackers are already using to take over administrator accounts without credentials. Here’s what’s affected, how the attack works, how to spot it in your logs, and the fixed release for each branch.

What You Need to Know

Metabase has disclosed CVE-2026-72898, a CVSS 10.0 SQL injection vulnerability that gives a remote, unauthenticated attacker administrator access to Metabase Open Source and Enterprise.

• Attackers exploited it as a 0-day against Metabase’s own cloud environment.
• Public PoC code is available.
• CISA has added it to the Known Exploited Vulnerabilities catalog.

Metabase Cloud is patched. Self-hosted deployments on branches x.58 through x.63 need to upgrade immediately.

What’s Vulnerable

CVE-2026-72898 affects the password-reset process in release branches x.58 through x.63. That starts with version 0.58.0 for Open Source and 1.58.0 for Enterprise. Versions earlier than x.58 aren’t affected.

The flaw is in the publicly accessible POST /api/session/reset_password endpoint, which doesn’t safely handle attacker-controlled data. A crafted user_id value containing a raw SQL expression skips the type validation it should get and reaches Metabase’s database query layer. That lets an attacker inject arbitrary SQL into the Metabase application database. Attackers use this to insert a valid session tied to the initial Metabase user, usually an administrator. They can then log in without knowing any credentials.

Admin access reaches well beyond the Metabase interface. An attacker can:

• change application settings
• create API keys
• steal credentials stored for connected databases
• run authorized queries against those systems
• export any business data they can reach

Why This Matters

Metabase usually sits in the middle of an organization’s data and holds stored credentials for warehouses and production databases. A takeover works like a skeleton key to everything Metabase connects to.

The flaw doesn’t directly wipe connected databases. But stolen credentials and admin access could enable destructive actions anywhere the associated database accounts have write or administrative privileges.

Exploitation in the wild is confirmed and PoC code is public. Assume any internet-facing instance on an affected version has been targeted, whether or not routine scanning has flagged anything.

What to Do

Upgrade to the fixed release for your branch:

• Open Source: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, or 0.63.5
• Enterprise: the corresponding 1.x release

If you can’t upgrade right away, block external access to /api/session/reset_password with a reverse proxy, WAF, or network control.

To check for exploitation, look for this sequence in your logs:

1. A POST request to that endpoint that returns HTTP 400.
2. Followed by a GET /api/user/current request that returns HTTP 200.

Then take these steps:

• Invalidate active sessions.
• Review administrator accounts and API keys.
• Rotate credentials for every connected database.
• Go through Metabase activity, query history, web logs, and data-warehouse logs for unauthorized access or bulk exports.

Treat any internet-accessible instance running an affected version as potentially compromised.

Splunk Search Head Clusters Exposed Through an Unauthenticated Patroni API

The Patroni REST API in some Splunk Enterprise releases skips authentication, which leaves search head clusters open to remote command execution. We cover affected versions, the exploitation chain, and a workaround for teams that can’t upgrade yet.

What You Need to Know

Splunk has patched CVE-2026-76268, a CVSS v3.1 9.8 missing-authentication vulnerability in the Patroni REST API on Splunk Enterprise search head cluster members. An attacker who can reach the API over the network can run commands on the host. They don’t need a Splunk account or any user interaction. Versions 10.2.0 through 10.2.6 and 10.4.0 through 10.4.2 are affected, and every vulnerable cluster member needs the fix.

What’s Vulnerable

Only the 10.2 and 10.4 release lines are affected. Versions 9.4.x and 10.0.x are not.

Patroni manages the PostgreSQL sidecar that certain Splunk capabilities use. Its REST API allows critical configuration operations, and affected releases accept them without authentication.

Published research describes the classic Patroni exploitation chain:

1. The attacker modifies the PostgreSQL configuration through the API.
2. They set archive_command to a command they control.
3. They trigger a restart, which runs that command with the PostgreSQL process’s privileges.

The result is command execution on the search head cluster member. That can expose Splunk data, configuration files, credentials, and other systems reachable from the compromised host.

The CVSS vector reflects:

• network access
• low attack complexity
• no required privileges
• no user interaction
• high impact to confidentiality, integrity, and availability

Splunk credited the discovery to its internal team.

Why This Matters

How exposed you are depends on your architecture. An attacker has to reach the Patroni API on a vulnerable cluster member. A well-segmented deployment is much better protected than one where the API is broadly reachable. Even so, internal network access, compromised administrative infrastructure, or an unintended service exposure could all provide that path.

Splunk published its advisory with no confirmed reports of active exploitation. However, public technical details and a Nuclei template make vulnerable systems easier to find.

A compromised search head is an especially bad outcome. It’s often the same system defenders rely on to detect the compromise.

What to Do

Upgrade every affected search head cluster member to Splunk Enterprise 10.2.7 or 10.4.3, or a later supported release. Updating only one node leaves the other vulnerable members exposed. Restrict the Patroni API to required cluster communication, and confirm it isn’t reachable from user networks or the internet.

If you can’t upgrade immediately and don’t use Edge Processor, OpAmp, or SPL2 data pipelines, Splunk recommends disabling the PostgreSQL sidecar:

1. Set disabled = true under the [postgres] stanza in $SPLUNK_HOME/etc/system/local/server.conf.
2. Restart Splunk.

Review network and host telemetry for unexpected requests to Patroni’s configuration and restart functions, especially PATCH /config followed by POST /restart. Investigate any of these coming from the sidecar context:

• unexplained PostgreSQL child processes
• configuration changes
• operating-system commands

Armory Castle Exploits BeyondTrust Remote Support 0-Day

A suspected China-nexus espionage group has been exploiting a BeyondTrust Remote Support 0-day since August 2026. The group uses compromised appliances as a launch point into downstream systems. We lay out the vulnerability, the attackers’ toolkit, and what recovery should look like for self-hosted customers.

What You Need to Know

BeyondTrust has disclosed CVE-2026-102764, a CVSS v4.0 9.3 vulnerability in Remote Support. It lets an unauthenticated remote attacker perform unauthorized file operations on vulnerable appliances, and it was exploited in the wild before a patch existed.

• SaaS environments were patched by October 9.
• Self-hosted deployments through version 26.2.3 require customer action.
• Treat any appliance that was reachable from the internet as potentially compromised.

What’s Vulnerable

CVE-2026-102764 comes from improper origin validation in an internal messaging component of Remote Support. Under the required conditions, an attacker can impersonate a trusted entity and perform unauthorized file operations on the appliance. The flaw affects supported Remote Support versions through 26.2.3. SaaS customers are already covered.

What Happened

Google Threat Intelligence Group and Mandiant attributed the activity to Armory Castle, a suspected China-nexus espionage group previously tracked as UNC5221 and Warp Panda.

After gaining access, the attackers deployed SAWFLY, an obfuscated PHP web shell with encrypted command-and-control and interactive code execution. They escalated privileges in three steps:

1. They copied /bin/sh to /usr/bin/dbus-authd.
2. They gave it root ownership.
3. They set the SUID permission.

That gave them persistent root-level execution on the appliance.

From there, the attackers:

• accessed secrets through BeyondTrust’s proprietary bt-secrets utility
• modified configuration templates to get passwordless root access
• used compromised administrator credentials to launch remote sessions against downstream systems listed as Jump Items

BARECLAW, a custom C-based SOCKS5 proxy, handled network tunneling through the compromised appliance. The operators modified /ns/config/haproxy.conf to expose the tunneler externally. They also deleted system, web server, and application logs to obstruct forensic investigation.

Why This Matters

Remote support appliances are trusted by design to reach into other systems. Compromising one gives an attacker stored credentials and a sanctioned path to everything behind it.

The attackers’ persistence methods are built to survive a patch:

• a root SUID shell disguised as a system binary
• modified templates
• an externally exposed tunnel

Because logs were deleted, a lack of evidence on the appliance proves very little. If a vulnerable appliance was reachable from the internet during the exploitation window, don’t consider it clean just because the patch is now installed.

What to Do

Self-hosted customers on Remote Support versions 24.3.1 through 26.2.3 should install the BT26-05-RS patch. If you’re on a version older than 24.3.1, upgrade first, then apply the remediation.

Preserve external firewall and reverse-proxy logs. Then inspect appliances for:

• unexpected PHP files
• SAWFLY or BARECLAW artifacts
• /usr/bin/dbus-authd
• SUID-enabled binaries
• changes to haproxy.conf
• altered startup files
• suspicious vault access
• gaps in logging

Review Remote Support administrator activity and downstream sessions for unauthorized access.

If exploitation is confirmed or can’t be ruled out, rebuild the appliance from a clean, patched image. That gives you stronger assurance than a reboot or configuration reset.

Rotate credentials stored or brokered by the appliance only after you’ve removed the attacker’s persistence. If you rotate first, the attacker can capture the new credentials.

PEERSTITCH Hides Inside FortiGate Daemons to Smuggle VPN Sessions

Unit 42 has uncovered PEERSTITCH, a memory-only implant that hooks FortiOS’s logging and VPN processes so attackers can slip past authentication. We cover the intrusion chain, how the implant works, and how to hunt for malware that leaves almost nothing on disk.

What You Need to Know

Palo Alto Networks Unit 42 has identified PEERSTITCH, previously undocumented memory-resident malware deployed against FortiGate firewalls by the activity cluster CL-STA-0954, also known as UNC5820. The attack had two stages:

1. The attackers exploited CVE-2024-47575 (FortiJump) against a telecommunications managed service provider’s FortiManager. They stole data tied to more than 500 managed firewalls.
2. They then used CVE-2025-61624 to plant the implant on selected devices.

Fortinet has confirmed active exploitation. Patching alone won’t undo the data theft.

What Happened

The FortiJump exploitation gave the attackers the provider’s configurations, cryptographic material, databases, credentials, network details, and information on its managed FortiGate fleet. They combined that stolen access with CVE-2025-61624 to deploy PEERSTITCH on selected devices.

CVE-2025-61624 is a path traversal vulnerability in the command-line interpreter of FortiOS, FortiPAM, FortiProxy, and FortiSwitchManager. A privileged attacker can use it to write or delete arbitrary files by crafting arguments to existing commands. Fortinet patched it in April 2026.

How PEERSTITCH Works

PEERSTITCH is a 64-bit Linux ARM64 implant designed to avoid conventional file- and network-based detection.

The deployment chain downloads JavaScript, WebAssembly, and native components, then launches an executable named lldprx. That component uses ptrace to attach to the legitimate /bin/miglogd and /bin/iked processes. It then allocates executable memory, injects code, and redirects process execution.

The resulting hooks create a covert bridge between the FortiOS logging and VPN daemons:

1. The miglogd hook recognizes traffic carrying specific markers, including TCP port value 8550 and the address 169.254.0.1.
2. It passes the matching session identifier to iked.
3. When the VPN daemon sees the same tag, it follows an altered execution path that bypasses normal validation.

PEERSTITCH leaves no persistent binary on disk, opens no listening port, and makes no direct outbound connection. The attackers also used Apache’s native mod_md module to create an SSH reverse shell. They disrupted logging to remove forensic evidence.

Why This Matters

This campaign shows how one management-plane compromise at a service provider can spread to hundreds of downstream customer firewalls. The stolen configurations, passwords, certificates, and private keys stay valid after patching. An attacker can still get into a fully updated device using material taken months earlier.

PEERSTITCH’s design makes things worse. It has nothing on disk, no listener, and no outbound beacon, so file scans and network signatures find little. And a covert VPN bypass on a perimeter device gives an attacker a quiet, durable way back in.

What to Do

• Upgrade affected Fortinet products to releases that address CVE-2025-61624.
• Confirm that CVE-2024-47575 remediation is also in place.
• Rotate any credentials and cryptographic material that may have been exposed through FortiManager.
• Review managed-device relationships.
• Investigate any of these:
  • unknown administrators
  • auto-scripts containing traversal sequences
  • suspicious VPN sessions
  • unauthorized FortiManager registrations
  • unexpected changes to logging

For PEERSTITCH specifically, examine the live memory of miglogd and iked for anonymous 16 KB regions with read, write, and execute permissions. Because the implant lives only in volatile memory, disk-focused scans may come back clean. Stronger evidence of compromise is more likely to come from:

• unexplained daemon crashes
• telemetry gaps
• access to /proc/<pid>/mem
• altered process memory