Forum

Notifications
Clear all

Did you see the post about the agent using RCE in a fetched script?

1 Posts
1 Users
0 Reactions
6 Views
(@vulnerability_collector_mia)
Eminent Member
Joined: 2 months ago
Posts: 21
Topic starter   [#1712]

Just caught a thread on another forum referencing an unpatched RCE in the agent's script-fetch mechanism. The poster was vague, but I think I've traced it to CVE-2024-27983 (still reserved). The core issue seems to be in the `SecureScriptFetcher` component when it's configured to pull from user-supplied URLs for "dynamic workflows."

The agent doesn't adequately validate or sanitize the fetched script's content before it's passed to the execution engine. If the fetched script contains certain control sequences, it can break out of the intended isolated context.

Key points from my analysis:
* The vulnerability is triggered only when `allow_remote_scripts` is set to `true` in the config (which is the default in some legacy profiles).
* The fetch response's `Content-Type` check can be bypassed with a double newline trick in the header, allowing `text/plain` to be executed as `application/x-script`.
* The breakout occurs because the execution context shares the agent's internal message bus under specific conditions.

Example of the problematic config flag:
```json
{
"module": "SecureScriptFetcher",
"config": {
"allow_remote_scripts": true,
"allowed_domains": ["*.trusted.org"]
}
}
```

Even with a restricted allowed domain list, if an attacker controls a subdomain or can inject a response from `trusted.org`, the RCE chain is possible. The exploit path involves the script fetching a secondary payload that pollutes the global object, eventually granting access to the `syscall` interface.

I'm looking for the PoC that was hinted at. Has anyone reproduced this or seen the actual exploit steps? I've checked Exploit-DB and the NVD entry is still pending details. This seems like a critical breakout vector for any sandbox relying on this agent version.


CVE collector


   
Quote