SecMate’s automated analysis found three security issues in OP-TEE [1], the open-source Trusted OS for Arm TrustZone that is commonly deployed with Arm Trusted Firmware. All three corrupt memory in the privileged OP-TEE core. We reported them against commit f2a7ad0638aeff5243593b33cc56ad064cae7615.

Two received CVEs. The affected SHA-3 path shipped in 13 public OP-TEE releases, the PKCS#1 v1.5 path in 25, and the SE050 RSA NOPAD path in at least 18. The oldest issue had been present for more than six years. SecMate found all three automatically using locally deployable gpt-oss-20b and gpt-oss-120b models.

OP-TEE treated the third finding as a bug because our report did not demonstrate the initial compromise needed to establish a complete compromised-TA attack chain.

Core memory corruption matters because OP-TEE is responsible for keeping secrets isolated from Linux or Android.

Why OP-TEE matters

OP-TEE stands for Open Portable Trusted Execution Environment. On Arm TrustZone systems, it runs security-sensitive code and data separately from the normal operating system, usually Linux or Android [1].

That normal operating system is called the Rich Execution Environment (REE). OP-TEE runs on the protected side of the TrustZone boundary. The separation is meant to keep sensitive data, code, and execution isolated even if software in the normal world is compromised. The GlobalPlatform TEE architecture defines integrity and data confidentiality as core security properties. It also defines mechanisms for Trusted Application code confidentiality and isolation from the REE [2]. The protected properties include:

• confidentiality of sensitive data and keys
• integrity of code and data during execution
• confidentiality of Trusted Application code when provided by the implementation
• isolation from the normal operating system

OP-TEE is not limited to research platforms. TrustedFirmware.org describes it as widely used and deployed, and its official platform list includes maintained targets from STMicroelectronics, NXP, Texas Instruments, Renesas, Rockchip, and AMD/Xilinx [3] [4]. Other vendors use different secure environments, including Qualcomm TEE, Samsung TEEGRIS, and Apple’s Secure Enclave with sepOS [5] [6] [7]. A device with a TEE therefore does not necessarily run OP-TEE.

What Arm Trusted Firmware and OP-TEE actually are

Arm application processors implement two security states, the Normal World and the Secure World, selected by the NS bit and enforced in hardware by TrustZone. The idea is to keep a small, high-assurance environment isolated from a large, complex Rich OS such as Linux. Inside each world, the processor still has privilege levels, expressed as exception levels.

Arm Trusted Firmware (TF-A) [9] is a reference implementation of the firmware that commonly runs at the most privileged level, EL3. Its BL31 runtime acts as the Secure Monitor in this deployment model. It handles SMC (Secure Monitor Call) instructions, PSCI power management, world switches, and dispatch to a Trusted OS.

OP-TEE is the Trusted OS in the deployment shown below. It commonly runs as the BL32 secure payload at S-EL1, with Trusted Applications (TAs) at S-EL0. OP-TEE and TF-A are sibling TrustedFirmware.org projects. When deployed together, TF-A provides the monitor and dispatches calls to OP-TEE. From the Normal World, an application uses the GlobalPlatform TEE Client API. The call crosses into EL3 via SMC, and the monitor hands it to OP-TEE.

The boundary that matters here is inside the secure world. Trusted Applications run at S-EL0. The OP-TEE core runs above them at S-EL1 and handles privileged operations such as key storage, cryptographic services, and secure peripherals. A TA can call the core through syscalls, but it must never be able to write core memory.

These three issues break that boundary. The SHA-3 issue starts with an off-by-one. The other two start with unchecked size relationships. In all three, an unsigned subtraction wraps. The resulting size or offset makes memset or memcpy write outside its buffer.

The three findings

CVE-2026-40257 requires the Arm v8.2 SHA-3 acceleration path. CVE-2026-33662 affects builds registering RSA acceleration through CAAM, HiSilicon, Versal, or SE050, as listed in the OP-TEE advisory. The third issue requires the NXP SE050 RSA driver. These paths are platform-specific, but they ship on production hardware.

Scope and impact

OP-TEE’s published security scope excludes a deliberately malicious TA signed with a trusted TA key because the key holder is already part of the trusted computing base [8].

An attacker may first compromise a legitimate, signed TA through one or more separate vulnerabilities and then invoke the SE050 bug through that TA. In this chain, the attacker does not need the TA’s signing key, and the TA retains its valid signature. Our report demonstrated the resulting controlled write from S-EL0 into S-EL1 core memory, but it did not demonstrate the initial TA compromise. OP-TEE therefore treated the finding as a bug rather than a complete vulnerability report.

Findings 1 and 2 do not have that prerequisite. Valid hash input triggers the first. A signing operation with a sufficiently small RSA modulus reaches the second.

All three are heap writes. Stack protection does not help. ASLR and non-executable data make targeted exploitation harder, but the minimum demonstrated impact for findings 1 and 2 is a secure-world crash. Finding 3 gives the attacker control over both the bytes written and their position relative to the allocation.

Finding 1: SHA-3 accelerated finalize heap overflow (CVE-2026-40257)

OP-TEE has two SHA-3 implementations. The default software implementation in sha3.c accumulates input word by word and is not affected by this issue. The other, sha3_accel.c, is compiled in when a platform enables the Arm v8.2 SHA-3 crypto extensions (CFG_CRYPTO_WITH_CE82=y) and buffers input in blocks. It is the accelerated path that is broken.

The Keccak sponge processes input in blocks of block_size bytes (136 for SHA3-256). sha3_process() is supposed to: finish any partial block, run full blocks through the hardware, then buffer the remainder. The bug is an off-by-one in step two:

 1/* sha3_accel.c:151 - strict greater-than is the bug */
 2if (inlen > block_size) {
 3    block_count = inlen / block_size;
 4    crypto_accel_sha3_compress(state, in, block_count, digest_size);
 5    in += block_count * block_size;
 6    inlen -= block_count * block_size;
 7}
 8
 9/* lines 159-160 - reached when inlen == block_size */
10memcpy(md->sha3.sb + md->sha3.byte_index, in, inlen);
11md->sha3.byte_index += inlen;            /* byte_index becomes block_size */

When a TA feeds exactly one block (136 bytes) with an empty buffer, inlen > block_size is false, the hardware compression is skipped, and the whole block is copied into sb with byte_index left equal to block_size. The finalize functions assume the invariant byte_index < block_size. It no longer holds:

1/* sha3_done(), lines 194-195 */
2buf[md->sha3.byte_index++] = 0x06;                              /* sb[136], index -> 137 */
3memset(buf + md->sha3.byte_index, 0, block_size - md->sha3.byte_index);
4/* block_size(136) - byte_index(137) underflows to 0xFFFFFFFF */

block_size - byte_index is 136 - 137 in unsigned arithmetic, i.e. 0xFFFFFFFF. The memset then writes roughly 4 GB of zeroes starting inside the hash state on the S-EL1 heap. sha3_shake_done() has the identical pattern for SHAKE-128/256.

Attack chain and impact. The trigger is two ordinary GlobalPlatform calls: TEE_DigestUpdate(op, data, 136) then TEE_DigestDoFinal(...). No special key material, permissions, or object types are required. The input is valid because hashing a block-sized buffer is normal usage. A perfectly honest TA can therefore crash the secure world without intending to. The write consists of zeroes and spans roughly 4 GB. In practice, it crashes the OP-TEE core and takes down its TAs, secure services, and Normal-World clients. The write offers too little control for a realistic code-execution primitive. The advisory rates it Moderate, CVSS 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).

We reproduced it with an ASAN harness that #includes the real sha3_accel.c, stubs the hardware compress function, and runs the two-call sequence. ASAN reports a heap-buffer-overflow with the stack pointing straight at sha3_accel.c:195.

Introduced by commit 1478437e65c4 in March 2023, this vulnerability shipped in 13 public OP-TEE releases, from 3.21.0 through 4.10.0. It remained in the secure-world core for nearly three years before SecMate’s automated analysis identified it, and for more than three years before the fix was merged.

The fix. Change the comparison so a full block is actually compressed, and add a defensive assertion to the finalize paths [10]:

1-	if (inlen > block_size) {
2+	if (inlen >= block_size) {
3 		block_count = inlen / block_size;
4 		crypto_accel_sha3_compress(state, in, block_count, digest_size);
5...
6+	LTC_ARGCHK(md->sha3.byte_index < block_size);
7+
8 	buf[md->sha3.byte_index++] = 0x06;
9 	memset(buf + md->sha3.byte_index, 0, block_size - md->sha3.byte_index);

With >=, an exact-block input is consumed by the hardware compress, inlen drops to zero, and byte_index stays at zero. The added LTC_ARGCHK returns CRYPT_INVALID_ARG if the invariant is violated again. The advisory identifies OP-TEE 4.11.0 and later as patched. The workaround is CFG_CRYPTO_WITH_CE82=n.

Finding 2: RSASSA PKCS#1 v1.5 encode underflow (CVE-2026-33662)

This one lives in the generic crypto-driver framework (CFG_CRYPTO_DRIVER=y), which platforms with RSA acceleration use to dispatch signature operations: NXP CAAM (plat-imx, plat-ls), Xilinx Versal, HiSilicon, and SE050 builds.

PKCS#1 v1.5 signature encoding pads the DigestInfo structure up to the modulus size with 0xFF bytes. emsa_pkcs1_v1_5_encode() computes how many padding bytes it needs by subtracting from the modulus size, with no lower-bound check:

1/* rsassa.c:48-50 */
2ps_size  = ssa_data->key.n_size - 3;
3ps_size -= ssa_data->digest_size;
4ps_size -= 10 + hash_oid->asn1_length;
5...
6memset(buf, UINT8_MAX, ps_size);          /* line 75 */

With a 256-bit modulus (32 bytes) and SHA-256 (32-byte digest, 9-byte OID), the arithmetic is 32 - 3 - 32 - (10 + 9), which underflows size_t to roughly SIZE_MAX. The memset then writes 0xFF across the entire S-EL1 heap until OP-TEE faults. RFC 3447 Section 9.2 mandates the missing size check [12]. The same file’s noasn1 and PSS paths already perform their own size validation. This path did not.

Attack chain and impact. A TA uses a sufficiently small RSA modulus and calls TEE_AsymmetricSignDigest(TEE_ALG_RSASSA_PKCS1_V1_5_SHA256, ...). The vulnerable core path is reached through that signing operation. Whether an external attacker can reach it depends on how the product exposes the TA to Normal-World clients. Like finding 1, this is a blunt overwrite. It gives an attacker a reliable TEE-wide denial of service, not controlled execution. The OP-TEE advisory rates the issue High, CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

SecMate identified this vulnerability independently before its public disclosure. OP-TEE had already found the issue internally, so the project handled our report as a duplicate and the CVE process was already underway.

This vulnerability was introduced by commit f5a70e3efb80 in February 2020. It remained in OP-TEE for more than six years and shipped in 25 public releases before the fix was merged in April 2026. Public Git history places the first affected release at 3.9.0, although the GitHub advisory lists versions from 3.8.0.

The fix. The maintainers replaced the chained subtraction with checked subtraction macros that bail out on underflow [11]:

1-	ps_size = ssa_data->key.n_size - 3;
2-	ps_size -= ssa_data->digest_size;
3-	ps_size -= 10 + hash_oid->asn1_length;
4+	if (SUB_OVERFLOW(ssa_data->key.n_size, 3, &ps_size) ||
5+	    SUB_OVERFLOW(ps_size, ssa_data->digest_size, &ps_size) ||
6+	    SUB_OVERFLOW(ps_size, 10 + hash_oid->asn1_length, &ps_size))
7+		return TEE_ERROR_BAD_PARAMETERS;

An encoding size that would make one of the subtractions wrap now returns TEE_ERROR_BAD_PARAMETERS. The patch prevents the memory corruption. It does not enforce the separate PKCS#1 v1.5 requirement that the padding string contain at least eight bytes. The advisory identifies OP-TEE 4.11 and later as patched. The workaround is to disable RSA acceleration.

Finding 3: SE050 RSA NOPAD controlled heap underflow

The third finding gives an attacker more control than the two CVEs, but OP-TEE treated it as a bug. It is in the NXP SE050 secure-element driver (CFG_NXP_SE05X=y), used on i.MX6/7/8 platforms that pair the SoC with an SE050 element over I²C.

decrypt_nopad() and encrypt_nopad() left-pad the caller’s input to the modulus size by computing a destination offset with, again, an unchecked unsigned subtraction:

1/* se050/core/rsa.c:356 (and :418) */
2rsa_len = crypto_bignum_num_bytes(key->n);     /* e.g. 256 for a 2048-bit key */
3memcpy(buf + rsa_len - src_len, src, src_len);

Neither the generic dispatch layer (crypto_acipher_rsanopad_decrypt, which passes cipher_len straight through) nor the SE050 driver checks that src_len <= rsa_len. If a TA supplies input larger than the modulus, the subtraction computes a destination before the allocation. Forming that pointer is undefined behavior in C. On the affected targets, it produces the following relative out-of-bounds write:

rsa_len = 256, src_len = 300  ->  256 - 300 = (size_t)-44
memcpy(buf - 44, src, 300)    ->  44 attacker-chosen bytes written BEFORE buf

buf comes from OP-TEE’s BGET-backed mempool. An allocated block’s prevfree and bsize metadata sit immediately before its payload, so even a short underflow can overwrite allocator state that mempool_free() later consumes.

Why this one is different. Findings 1 and 2 overwrite with a fixed byte over an unbounded range, which is useful for a crash but offers little control. This is a controlled heap-underflow write primitive: the attacker chooses the underflow distance (src_len - rsa_len) and the bytes copied from src. The primitive can corrupt allocator metadata or an adjacent core object before the affected allocation is freed. We did not build a complete S-EL0-to-S-EL1 exploit, but this gives an attacker far more control than findings 1 and 2, especially on constrained 32-bit targets. We confirmed the out-of-bounds write with an ASAN harness around the real rsa.c.

The vulnerable RSA NOPAD implementation entered the SE050 driver in commit 462192731c92 in January 2022. It shipped in at least 18 public releases and was still present in upstream commit 611fbaf34150 on July 13, 2026, four and a half years later.

Why it was treated as a bug. Reaching this code requires control of a TA that calls TEE_AsymmetricDecrypt(TEE_ALG_RSA_NOPAD, ...) with oversized input. That control could come from a deliberately malicious TA or from compromising a legitimate, signed TA through another vulnerability. The former is outside OP-TEE’s threat model; the latter does not require the attacker to possess a TA signing key and can form the first stage of an exploit chain. Our report demonstrated the controlled S-EL1 write but not the initial TA compromise, so OP-TEE treated the finding as a bug.

The fix is to validate src_len <= rsa_len and msg_len <= n_size in the generic dispatch layer, then repeat the check in the driver before memcpy. The HiSilicon HPRE driver already validates input sizes independently and is not affected.

Three old flaws, found automatically

These issues entered OP-TEE in 2020, 2022, and 2023. They survived across separate accelerated implementations and hardware drivers until SecMate’s automated analysis found them.

Every issue in our public disclosure record [13] was found by the same engine. SecMate runs with locally deployable models, so vulnerability research can stay inside the operator’s environment instead of sending source code to an external model service.

Disclosure timeline

References

• [1] OP-TEE. “About OP-TEE.” OP-TEE documentation. Documentation

• [2] GlobalPlatform. “TEE System Architecture v1.3.” Specification

• [3] OP-TEE. “Platforms supported.” OP-TEE documentation. Documentation

• [4] TrustedFirmware.org. “OP-TEE moving into Trusted Firmware.” Project announcement

• [5] Qualcomm. “Qualcomm Linux System Software Architecture.” Documentation

• [6] Samsung. “Samsung TEEGRIS.” Samsung Developer. Documentation

• [7] Apple. “The Secure Enclave.” Apple Platform Security. Documentation

• [8] OP-TEE. “Security scope.” OP-TEE documentation. Documentation

• [9] TrustedFirmware.org. “Firmware Design.” Trusted Firmware-A documentation. Documentation

• [10] OP-TEE. “SHA-3 accelerated finalize heap overflow.” GHSA-75x4-j8p9-55qv / CVE-2026-40257. Advisory

• [11] OP-TEE. “RSASSA EMSA-PKCS1-v1_5 underflow in emsa_pkcs1_v1_5_encode().” GHSA-4cf8-v5g3-73gr / CVE-2026-33662. Advisory

• [12] IETF. “PKCS #1: RSA Cryptography Specifications Version 2.1.” RFC 3447. Specification

• [13] SecMate. “Disclosures.” Disclosure page

The SecMate Team

SecMate found seven vulnerabilities in Renesas FSP [1], the Flexible Software Package for Renesas RA microcontrollers [2]. FSP is the vendor software stack for RA devices and bundles BSP code, HAL drivers, middleware, and security integrations, including hardware-backed cryptography and Mbed TLS support.

In the v6.1.0 FSP codebase we analyzed at commit ed247f90fb9bc390ebd36f1a0b7847b0ff44f322 [3], we found issues in RSA verification, the hardware-accelerated AES-XTS path, GCM decrypt handling, and the RMAC receive path. These are implementation flaws in FSP integration code around hardware-backed cryptography and networking. They are not flaws in AES, GCM, CCM, XTS, or RSA as algorithms.

Advisory Map

The AES-XTS advisory covers two findings, one in the encrypt finalization path and one in the decrypt finalization path.

Affected Builds and Use Cases

SecMate’s published disclosure advisories are available on the SecMate disclosures page [4]. The table above links both the SecMate advisory and the corresponding Renesas public advisory for each vulnerability group.

These cryptography-related findings do not apply to every RA build. In FSP, the accelerated AES and AEAD paths are compiled for devices with SCE5, SCE5B, SCE7, SCE9, or RSIP support, and the XTS path is excluded on RA2 parts.

In downstream products, these APIs may be used for signature verification, authenticated decryption, encrypted storage, firmware update, or other security-sensitive processing. Exposure therefore depends on whether untrusted inputs can reach those wrappers.

The RMAC finding is separate from the cryptographic code paths. It affects products using the Ethernet receive API if application code provides a buffer smaller than the received frame.

Renesas PSIRT acknowledged the reports and published public advisories on GitHub.

Recommendations

• If you use affected RA builds, review the Renesas advisories and update to FSP v6.3.0 or later.
• In downstream products, check whether untrusted inputs can reach FSP wrappers used for signature verification, authenticated decryption, encrypted storage, or firmware update handling.
• Add negative tests for malformed signatures, AEAD metadata, XTS lengths, and oversized Ethernet frames.
• If you use r_rmac, verify that receive buffers are sized for the largest frame your product accepts.

Timeline

Takeaway

The common thread is not broken cryptography. It is memory safety in the FSP code that exposes cryptographic and Ethernet functionality to RA applications. Hardware-backed cryptography still depends on the surrounding integration code.

For the full list of our disclosures, see our disclosure page [4]. If you are building embedded systems and want to find vulnerabilities before attackers do, reach out.

References

• [1] Renesas. “Renesas Flexible Software Package.” GitHub. Repository

• [2] Renesas. “Renesas Flexible Software Package Documentation.” Documentation

• [3] Renesas. “FSP v6.1.0 analyzed commit” (ed247f90fb9bc390ebd36f1a0b7847b0ff44f322). Commit

• [4] SecMate. “Disclosures.” Disclosure page

• [5] Renesas. “FSP v6.3.0.” GitHub Releases. Release

The SecMate Team

Rust is often praised for its memory safety guarantees, and rightfully so: in safe Rust, buffer overflows, use-after-free, and data races are eliminated at compile time. However, memory safety is not the same as security. Logic bugs, authentication flaws, and improper error handling can still leave Rust applications vulnerable.

To illustrate this, we ran SecMate’s automated analysis on RustFS [1], an S3-compatible object storage server written in Rust. We found two issues: an authentication bypass that lets attackers spoof their IP address to circumvent access controls (CVE-2026-21862 [2]), and a remote denial-of-service caused by unhandled deserialization errors (CVE-2025-69255 [3]).

Rust Support in SecMate

SecMate is an AI-powered static analysis tool specialized in the security of embedded software. We combine static analysis techniques with AI to find vulnerabilities that traditional tools miss: logic bugs, authentication flaws, and subtle design issues that require understanding how data flows through a system.

Rust is increasingly adopted in embedded and systems programming for its memory safety guarantees. Firmware, bootloaders, and security-critical components are being rewritten in Rust to eliminate entire classes of vulnerabilities. To support this trend, we recently added Rust to our analysis engine.

While RustFS is not an embedded application, it made an excellent first target: it is a security-sensitive system handling authentication, access control, and network protocols. This is the kind of complex logic where vulnerabilities hide regardless of the language.

What is RustFS?

RustFS is an S3-compatible object storage server written in Rust. Think of it as a self-hosted alternative to Amazon S3: you can store and retrieve objects using the same API that countless applications already support.

Key features include:

• Full S3 API compatibility for drop-in replacement
• IAM policies for fine-grained access control
• gRPC interface for cluster administration and metrics
• Support for erasure coding and distributed deployments

RustFS is designed for performance and reliability. It handles sensitive data and access control decisions, making security critical.

Vulnerability #1: IP-Based Authentication Bypass (CVE-2026-21862)

Location: rustfs/src/auth.rs:294 (get_condition_values)

The Bug

RustFS supports IAM policies that restrict access based on the client’s IP address. This is a common pattern: allow operations only from trusted networks, block everything else.

This feature exists because RustFS is often deployed behind a reverse proxy or load balancer. In that setup, every TCP connection appears to come from the proxy, not the real client. To preserve the original client address, proxies add forwarding headers like X-Forwarded-For, and applications use them for both access control and logging. That design only works if the proxy is trusted.

The problem is how RustFS determines the client’s IP. It reads forwarding headers like X-Forwarded-For or X-Real-IP and trusts them unconditionally:

1let remote_addr = header
2    .get("x-forwarded-for")
3    .and_then(|v| v.to_str().ok())
4    .and_then(|s| s.split(',').next())
5    .or_else(|| header.get("x-real-ip").and_then(|v| v.to_str().ok()))
6    .unwrap_or("127.0.0.1");
7
8args.insert("SourceIp".to_owned(), vec![get_source_ip_raw(header, remote_addr)]);

RustFS never verifies that the request actually came through a trusted proxy. Any client can set these headers directly.

The Attack

An attacker can bypass IP-based access controls by simply adding a forged header to their request:

Here is what happens step by step:

1. An IAM policy allows s3:ListBucket only from IP 10.0.0.5/32 (an internal server)
2. The attacker connects from their external IP 1.2.3.4
3. They add the header X-Forwarded-For: 10.0.0.5 to their request
4. RustFS reads the header and believes the client IP is 10.0.0.5
5. The IAM policy check passes, and the attacker gets access

Impact

This vulnerability bypasses IP-based access controls when headers are attacker-controlled, such as when clients connect directly to RustFS or through an untrusted proxy. If a trusted proxy controls or strips these headers before forwarding, the risk is reduced. However, in deployments where clients can reach RustFS directly, aws:SourceIp conditions become bypassable. An attacker can:

• Access buckets restricted to internal networks
• Bypass IP allowlists meant for trusted services
• Circumvent geographic restrictions
• Spoof audit trails and security monitoring by forging client IPs
• In the version we analyzed, missing headers fell back to 127.0.0.1, so policies allowing localhost could unintentionally allow remote requests

Fix Status

This vulnerability has been fixed. RustFS now:

• Provides an environment variable (_RUSTFS_API_XFF_HEADER) to disable forwarding header processing entirely
• Falls back to the actual TCP connection’s peer address when headers are missing or disabled
• Operators deploying RustFS without a trusted proxy should set _RUSTFS_API_XFF_HEADER=off

Vulnerability #2: Remote DoS via gRPC Panic (CVE-2025-69255)

Location: rustfs/src/storage/tonic_service.rs:1768-1785 (get_metrics)

The Bug

RustFS exposes a gRPC interface for cluster operations, including a GetMetrics endpoint. The handler deserializes client-supplied bytes using Deserialize::deserialize() and calls .unwrap() on the result:

1// In NodeService::get_metrics handler
2let t = Deserialize::deserialize(&mut buf_t).unwrap();  // Panics on bad input!
3let o = Deserialize::deserialize(&mut buf_o).unwrap();  // Same problem here

In Rust, .unwrap() is convenient for cases where failure is truly unexpected. But here, the input comes from the network. An attacker controls what bytes get deserialized. If they send malformed data, deserialization fails, and .unwrap() triggers a panic, aborting the request.

RustFS does wrap request handling in a panic-catching layer, so a single panic usually returns an error instead of killing the whole process. That limits the blast radius, but panics are still expensive to handle.

The Attack

The attack requires sending a malformed gRPC request. When a client sends an empty or invalid metric_type field, the server attempts to deserialize it, fails, and the .unwrap() call causes a panic:

When the malformed request arrives, the server logs a panic:

thread 'rustfs-worker' panicked at rustfs/src/storage/tonic_service.rs:1778:66:
called `Result::unwrap()` on an `Err` value: InvalidMarkerRead(Error {
    kind: UnexpectedEof,
    message: "failed to fill whole buffer"
})

Impact

This was a remote denial-of-service risk. The gRPC endpoint uses HMAC signature authentication via x-rustfs-signature and x-rustfs-timestamp headers. A single bad request only affected that one request, but repeated exploitation could cause a real denial-of-service. An attacker with valid credentials could send many malformed requests (or parallelize them across connections) to repeatedly trigger panics, which:

• Consumed CPU time in panic handling and stack unwinding
• Flooded logs with panic traces and slowed down observability pipelines
• Starved gRPC worker threads so GetMetrics became effectively unavailable
• Could slow other gRPC handlers that share the same runtime under high load

The fix was straightforward: replace .unwrap() with proper error handling that returns an error response instead of panicking:

 1// Fixed version
 2let t: MetricType = match Deserialize::deserialize(&mut buf_t) {
 3    Ok(t) => t,
 4    Err(err) => {
 5        return Ok(Response::new(GetMetricsResponse {
 6            success: false,
 7            error_info: Some(format!("Invalid metric_type: {err}")),
 8            ..Default::default()
 9        }));
10    }
11};

Fix Status

This vulnerability has been fixed in current RustFS versions. The .unwrap() calls are gone, and deserialization errors now return a response with success=false and an error string instead of panicking. The fix includes tests to ensure invalid metric_type and opts values do not cause panics.

The Rust Security Reality

Both vulnerabilities highlight an important point: Rust’s safety guarantees have limits.

In safe Rust, entire classes of memory-safety bugs are eliminated at compile time. You will not find buffer overflows, use-after-free, or data races in safe Rust code. This is a huge win for security.

But Rust does not prevent:

• Logic bugs: Trusting user-controlled headers for authentication decisions
• Error handling mistakes: Using .unwrap() on fallible operations with untrusted input
• Design flaws: Exposing sensitive endpoints without proper authentication
• Cryptographic errors: Using weak algorithms or improper key management

Key Insight

Memory safety is necessary but not sufficient for security. Rust eliminates one category of vulnerabilities, but logic bugs and design flaws require the same careful analysis as in any other language.

These findings demonstrate why AI-assisted code analysis remains valuable even for memory-safe languages. SecMate identified these vulnerabilities by analyzing data flow and reasoning about how untrusted input affects security decisions, something that applies regardless of the language.

Disclosure Timeline

We thank the RustFS maintainers for their responsiveness in addressing these issues. Coordinated disclosure helps keep the ecosystem secure.

Want to Know More?

These two CVEs are the first vulnerabilities we are publicly disclosing in a Rust codebase, showcasing SecMate’s expanded language support. As Rust adoption grows in systems programming and embedded development, we expect to find more issues like these: logical flaws that memory safety alone cannot prevent.

Interested in our vulnerability research? Browse our public disclosures to see what else we have found. If you want SecMate to analyze your codebase, whether it is Rust, C, C++, or another language, get in touch.

References

• [1] RustFS. “RustFS - High Performance Object Storage” GitHub. Repository | Documentation

• [2] GitHub. “GHSA-fc6g-2gcp-2qrq - SourceIp bypass via spoofed X-Forwarded-For/Real-IP headers” GitHub Security Advisory. Advisory

• [3] GitHub. “GHSA-gw2x-q739-qhcr - RustFS gRPC GetMetrics deserialization panic enables remote DoS” GitHub Security Advisory. Advisory

The SecMate Team

We discovered two memory-safety issues in libcoap, a widely deployed IoT library. The first is an out-of-bounds write in a fixed buffer reachable via proxy requests that can crash servers with a single UDP packet. The second is an out-of-bounds read in OSCORE configuration parsing that can crash the parser on malformed input. Both vulnerabilities have amplified impact on the constrained embedded devices the library was built for.

About SecMate

SecMate combines static analysis with AI to find security vulnerabilities in source code, specifically in embedded devices and low-level code.

So far, we have reported more than 60 vulnerabilities across embedded and systems projects, most still under coordinated disclosure.

Today, we are sharing two of our findings in libcoap (the first two CVEs uncovered with SecMate), a widely-used CoAP implementation for IoT devices.

What is libcoap?

libcoap [1] is a C implementation of the Constrained Application Protocol (CoAP), standardized as RFC 7252 [2]. Think of CoAP as “HTTP for IoT”: a lightweight protocol for devices that can’t afford the overhead of full HTTP/TCP stacks.

The library is mature and widely deployed:

• Supports multiple TLS backends (OpenSSL, GnuTLS, Mbed TLS, wolfSSL)
• Runs on everything from Linux servers to ESP32 microcontrollers
• Used in smart home devices, industrial sensors, and critical infrastructure

Here is the catch: the devices running libcoap are often constrained. Limited memory, no MMU, no ASLR, no stack canaries. When you find a memory-safety issue in this context, the impact is amplified.

Vulnerability #1: Static Buffer Overflow in Address Resolution (CVE-2025-34468 [3])

Location: coap_resolve_address_info() in src/coap_address.c

The Bug

This vulnerability affects libcoap servers running in proxy mode. The vulnerable function resolves hostnames for CoAP proxy requests, copying the hostname into a fixed 256-byte static buffer without checking the length:

1static char addrstr[256];  // Fixed-size static buffer
2memset(addrstr, 0, sizeof(addrstr));
3if (address && address->length)
4    memcpy(addrstr, address->s, address->length);  // No bounds check!
5else
6    memcpy(addrstr, "localhost", 9);
7getaddrinfo(addrstr, NULL, &hints, &res);

The address->length field comes directly from parsing CoAP options. An attacker controls this value.

The Attack

When a CoAP server runs in proxy mode, it accepts Proxy-Uri options that specify where to forward requests. The hostname from this URI flows directly into the vulnerable memcpy():

1. A CoAP request arrives with a Proxy-Uri option containing an oversized hostname (>256 bytes)
2. The proxy extracts the hostname and passes it to coap_resolve_address_info()
3. The function calls memcpy(addrstr, address->s, address->length) without bounds checking
4. The fixed-size buffer overflows, corrupting adjacent memory
5. The server crashes or misbehaves; the exact impact depends on layout and mitigations

Impact

On a standard Linux system, this bug is likely to crash the server (Denial of Service). On embedded devices without memory protection, memory corruption can have broader consequences, but practical exploitation depends on layout and mitigations. One UDP packet, no authentication required when proxy mode is enabled.

Vulnerability #2: Out-of-Bounds Read in OSCORE Parsing (CVE-2025-59391 [4])

Location: get_split_entry() in src/coap_oscore.c

The Bug

OSCORE (Object Security for Constrained RESTful Environments) is a security layer for CoAP. libcoap parses OSCORE configuration files that include boolean fields. The parsing code uses memcmp() with a user-controlled length:

1case COAP_ENC_BOOL:
2    if (memcmp("true", begin, end - begin) == 0)
3        value->u.value_int = 1;
4    else if (memcmp("false", begin, end - begin) == 0)
5        value->u.value_int = 0;

The problem: end - begin comes from the configuration file. If an attacker provides a value like trueAAAAAAAA... (thousands of characters), the memcmp() reads past the static string "true" into adjacent memory.

Impact

This issue requires the ability to provide malicious OSCORE configuration input, which is typically a local or trusted provisioning path rather than a network-facing vector. The realistic outcome is a crash or parse failure on malformed configs.

Theoretical Oracle Attack

In theory, if a local attacker could repeatedly provide different config files and observe success/failure signals from the parser, they could use this as an oracle to infer adjacent .rodata bytes one at a time. The diagram below illustrates what such an attack would look like:

However, this attack is impractical: OSCORE configuration is loaded from local files, so an attacker would need repeated local access to provide different config files and observe results. At that point, they likely have access that makes this leak scenario moot.

Why This Bug is Easy to Miss

This vulnerability is subtle: the out-of-bounds read in memcmp() may not crash or produce obvious symptoms during normal operation. Spotting it requires reasoning about how data flows through multiple operations, something traditional static analysis tools typically miss.

The Embedded Security Challenge

Both vulnerabilities share a common theme: they are worse on the devices libcoap is designed for.

Desktop and server systems have decades of hardening:

• ASLR randomizes memory layout
• Stack canaries detect buffer overflows
• DEP/NX prevents code execution from data segments
• Sandboxing limits blast radius

Constrained embedded devices often have none of these. A microcontroller running FreeRTOS or bare metal has:

• Flat, predictable memory layout
• No memory protection unit (MPU) or it is disabled for performance
• No operating system to enforce isolation
• Direct hardware access for any code that runs

This isn’t a criticism of libcoap. It is the reality of their target environment. But it means bugs like these deserve extra scrutiny.

Key Insight

When auditing code for constrained devices, assume the worst-case exploitation scenario. Mitigations you take for granted on desktop systems simply don't exist.

Disclosure and Fix

We reported both vulnerabilities to the libcoap maintainers through coordinated disclosure. The team responded quickly and professionally, and fixes are now available in version 4.3.5a.

Disclosure Timeline

We want to thank the libcoap team, particularly Jon Shallow, for their responsiveness in addressing these issues. The maintainer responded on the same day for both reports. Maintaining open-source security infrastructure is often thankless work, and their quick turnaround made the ecosystem safer.

What’s Next

These two CVEs are just a sample of what SecMate has found. We’re continuing to analyze embedded codebases and report vulnerabilities through coordinated disclosure.

If you’re curious about our other findings, check out our disclosure page. And if you’re building embedded systems and want to find vulnerabilities before attackers do, reach out.

References

• [1] libcoap. “libcoap - C-Implementation of CoAP” GitHub. Repository

• [2] IETF. “RFC 7252 - The Constrained Application Protocol (CoAP)” IETF Datatracker, June 2014. RFC

• [3] NVD. “CVE-2025-34468 - Static Buffer Overflow in libcoap” National Vulnerability Database. CVE

• [4] NVD. “CVE-2025-59391 - Out-of-Bounds Read in libcoap” National Vulnerability Database. CVE

The SecMate Team