Re-assessment of CVSS score required for CVE-2025-61765

[locus-x64]

Recently I discovered an RCE in python-socketio (details available here).

The maintainer of this project @miguelgrinberg has rated this vulnerability CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L but I would disagree with this assessment.
Three major points:

1. Attack Vector (AV:A - Adjacent): Should be AV:N (Network)

   • The vulnerability is exploitable over the network when message queues are accessible
   • No requirement for adjacent network access
     Explanation:
     AV:A reasonably reflects the intended deployment, but an argument could be made for AV:N if misconfiguration is considered.

2. Privileges Required (PR:H - High): Should be PR:N (None) or PR:L (Low)

   • No authentication is typically required to connect to misconfigured message queues
   • The vulnerability exists precisely because message queues lack proper access controls
     Explanation:
     This value assumes that only privileged internal components can connect to the queue. The PR text recommends enabling authentication and notes that the queue "is an internal component … not accessible from the public internet" . However, many queue servers allow anonymous connections by default (e.g., Redis with no password, Kafka topics without ACLs). An attacker who can reach the port may not need elevated system privileges—only the ability to write to a network socket. CVSS defines PR:H as requiring administrative‑level privileges. In this case, a low‑privileged user on the same network could exploit the vulnerability if the queue lacks authentication. Therefore PR:L (or even PR:N in misconfigured environments) seems more appropriate.

3. Availability (A:L - Low): Should be A:H (High)
   Explanation:
   This RCE lets an attacker terminate services, exhaust resources, or otherwise cause persistent denial of service , meeting CVSS v3.1’s High availability impact.
   https://www.first.org/cvss/specification-document

I would suggest:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

[Sim4n6]

Please consider sharing further details such as the exploit or a reproducible poc

[locus-x64]

I am writing a detailed blog post with PoC exploit that will be published on bluerock.io
The scenario that I used for the PoC is:

• There is a vulnerable/misconfigured server that is connected to a message queue (Redis Elasticache)
• The attacker uses this server's vulnerability to publish the malicious pickle payload to elasticache on the same channel A
• Now there is another server that is using socketio connected to elasticache. This server is loading each message pushed on elasiticache on its channel and deserializing using pickle.loads

In this scenario, the attacker doesn't need any elevated privileges to execute code on socketio server. Since the attacker can execute any arbitrary python code, it can exhaust resources or make server completely unavailable.

[locus-x64]

@Sim4n6 Here is a detailed blog post with a demo to support our suggested CVSS score:
https://www.bluerock.io/post/cve-2025-61765-bluerock-discovers-critical-rce-in-socket-io-ecosystem

[miguelgrinberg]

I have tried to explain my reasoning to the researcher when scoring the issue as I did.

Attack Vector (AV:A - Adjacent): Should be AV:N (Network)
The vulnerability is exploitable over the network when message queues are accessible
No requirement for adjacent network access

Message queues are always deployed for internal use of the server(s) in the deployment. They offer no functionality to clients, so there is no reason to configure them to listen on a public network port. AV:A recognizes that a remote attacker cannot mount an attack unless they find a way to infiltrate the private network of the deployment.

Checking a few Redis and Valkey deployment options, you can see that none of them default to deploying on a public port:

• Heroku deploys Valkey (Redis compatible) with TLS and authentication by default.
• AWS deploys Redis and Valkey as part of their Elasticache service with TLS and authentication as well.
• The official Redis Kubernetes operator (https://redis.io/docs/latest/operate/kubernetes) generates random passwords and enables TLS by default.
• The Ubuntu official package for Redis deploys redis on localhost by default, so no access from the outside is possible unless the server is compromised first.

Privileges Required (PR:H - High): Should be PR:N (None) or PR:L (Low)
No authentication is typically required to connect to misconfigured message queues
The vulnerability exists precisely because message queues lack proper access controls

Similar answer as above. Message queues are internally deployed for the servers to use. For single-server deployments they default to listening on localhost. For multi-server deployments they listen on a VPC. See examples of commonly used single and multi-server deployment strategies in the previous point. PR:H recognizes that the attacker needs to compromise one or more additional layers (SSH access, the queue's own authentication) to mount an attack.

Availability (A:L - Low): Should be A:H (High)
This RCE lets an attacker terminate services, exhaust resources, or otherwise cause persistent denial of service

This was admittedly the one that was hardest for me to score accurately. I decided on A:L because the attack does not give the attacker super user credentials. This is not to deny that this attack can cause a disruption, it certainly can. But the attacker will not be able to terminate or affect the functioning of the message queue aside from adding traffic to it, and will not be able to terminate the web server or affect other threads outside of the one that accepts pickled messages. And the thread in which messages from the queue are received is a background thread and it is not directly connected to user requests, so the web server will be able to continue receiving and responding to requests on other threads.

[Sim4n6]

Don’t get me wrong, but "when the wise man points at the moon, the fool looks at the finger." A bit harsh, perhaps, but it’s true. A malicious attacker would love this issue if it remained unmitigated. Even with a blind SSRF, an attacker could gain a comfortable foothold on the network.

What I reproach about Locus-x64 is that his argument stays somewhat theoretical. He sets the Availability metric to Low, but you could easily craft a payload that takes down an entire instance (A:H).

The truth, to me, is that the developer should adopt a worst-case scenario, similar to computing the algorithmic complexity. If the payload can be delivered over the network, that alone justifies setting AV:N.

The PR metric is a bit tricky. In my opinion, it is either Low or None. If the default setup has no password, I would pick PR:N, although that would imply a clearly misconfigured instance. PR:L makes sense when delivery requires an unguessable token that a regular user might have, but not admin privileges.

CVSS is a useful scoring system; it may seem a bit imperfect, but it is currently the reference on the matter. My suggestion may be different: AC:H, some conditions are beyond the attacker's control, and S:C the vulnerability can reach resources beyond the messaging system. My preferred vector is:

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H which scores 6.9 (High).

In the worst-plausible scenario (misconfigured messaging system), it becomes:

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H which scores 9.2 (Critical).