- SonicWall patched four SMA1000 flaws, including CVE-2026-102255, a CVSS 10 bug that lets an unauthenticated attacker make the appliance send requests for them.
- Splunk also patched three critical Splunk Enterprise bugs, plus a medium MCP Server flaw. Both vendors' fixes raise the question of who can steer a trusted system's requests.
- Check any SMA1000 appliances against versions 12.5.0-03082 or 12.4.3-03670, and ask which systems can reach internal services and where their outbound requests go.
The most useful way to read this week's SonicWall advisory is not as a break-in. The attacker does not need to get inside. The attacker asks a trusted machine to go inside on their behalf. That distinction shapes how a security team should respond.
What SonicWall and Splunk fixed
SecurityWeek reported on October 8 that both vendors had released security updates. The fixes cover flaws rated critical or high. Some of them would let an attacker run code of their choosing.
SonicWall fixed four vulnerabilities in its SMA1000 appliances. It told customers to move to versions 12.5.0-03082 or 12.4.3-03670. The most severe is CVE-2026-102255, which carries the maximum CVSS score of 10. The other three are two high-severity flaws and one medium-severity flaw. Between them they open routes to remote code execution and cross-site scripting (XSS).
Splunk announced fixes for dozens of flaws across Splunk Enterprise, its MCP Server and its Add-on for Amazon Web Services. Three of the Splunk Enterprise flaws are rated critical. Attackers could use them to run commands of their choosing, gain access they should not have, or inject code.
How the SonicWall flaw works
CVE-2026-102255 is a server-side request forgery bug, known as SSRF. It is pre-authenticated, meaning the attacker needs no login. SonicWall says the cause is an "unintended alternate access path."
Think of a building with a guarded front desk and a side door nobody remembered to lock. The desk checks every visitor. The side door does not. In software terms, the appliance enforces its checks on the intended route but not on a second route that reaches the same function.
SonicWall says a remote, unauthenticated attacker could abuse that path to make the appliance issue requests for them. Those requests could reach internal functionality and perform unauthorized operations. The attacker borrows the appliance's position inside the network. A VPN appliance is trusted by design, so what it asks for is rarely questioned.
SonicWall also made two limits clear. It says there is currently no evidence that any of the fixed flaws are being exploited in the wild. It also says SSL-VPN running on SonicWall Firewall products is not affected.
A related pattern in Splunk's MCP Server
One Splunk fix points the same way, at a smaller scale. The MCP Server patch covers a medium-severity defect. An authenticated user could change API settings so the server sends requests to an attacker-controlled URL. MCP is a standard that lets AI tools call other systems.
This is not the same bug as SonicWall's. It is medium severity and needs a login. Even so, it raises the same question: who decides where a trusted system sends its requests? As more automated tools hold credentials and make calls on a company's behalf, that question applies to more systems.
What leaders should ask their teams
First, ask whether any SMA1000 appliances are running. If so, confirm which version each one runs against the two fixed releases. Firewall SSL-VPN is outside this advisory, so do not treat the two as one inventory item.
Second, ask which systems can reach internal services on the network's behalf. VPN gateways, connectors and AI tool servers all qualify. For each one, ask who can change where it sends requests.
Third, ask whether outbound traffic from these systems is restricted to known destinations. A system limited to a short list of destinations is harder to turn into a messenger.
Fourth, for Splunk, ask which of the dozens of fixes apply to the deployed components, and where the third-party package fixes sit in the patch queue. Splunk's security advisories page lists the details.
The lesson here is that a trusted system is only as safe as the instructions it will accept. A patch closes one side door. The longer-term work is knowing which machines act for you, and who can talk to them.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: SecurityWeek.
