When analysing firmware attack surfaces, image decoders built into bootloaders get less scrutiny than cryptographically verified OS kernels. If image parsing happens before signature verification, any memory corruption in the parser breaks the secure boot trust model.

researchers analysed U-Boot's video subsystem (drivers/video/video_bmp.c) and identified an unbounded write in the RLE8 bitmap decoder (video_display_rle8_bitmap()) that leads to a pre-authentication Secure Boot bypass.

Root Cause and Vulnerability Mechanics

When U-Boot displays a boot logo or splash screen, it parses a BMP image loaded from local storage (SPI flash, MMC/eMMC, USB, or SD card).

Unbounded framebuffer write: During RLE8 decompression, video_display_rle8_bitmap() decodes run-length encoded streams directly into the active framebuffer without validating stream bounds against the frame boundary or allocated buffer size.

Pre-authentication execution window: In many embedded target configurations, the boot splash screen is rendered immediately on startup, before U-Boot calls Android Verified Boot (AVB) or FIT image signature verification routines.

Storage disparity: The kernel image and rootfs are signed, but splash images are frequently stored in unsigned, user-writable partitions or external media.

An attacker who writes a crafted RLE8 BMP to the boot storage can trigger an out-of-bounds write past the framebuffer during early boot, corrupting adjacent bootloader data structures, function pointers, or verification flags in memory.

This hijacks the execution flow before signature checking completes.

TL;DR. SConnect - 1M+ users, an extension middleware+native host for authentication with eIDs, 3SKeys and other hardware signing tokens had a drive-by RCE which enabled any site or iframe a user saw to silently download and execute a dll due to a poor hand-rolled implementation of RSA-2048 token validation, enabling a use of uninitialized memory validation bypass which enabled "plugins" (DLLs) to be loaded. v2.16.0.0 of the extension and native host is vulnerable. CVE-2026-18397. CVSS 9.4.

API Connections allow anyone to fully compromise any other connection worldwide, giving full access to the connected backend.

A blue-team writeup on detecting a compromised MikroTik from its own config. Seven techniques, each with the collection command, the artifact it leaves behind, and a triage step. Feedback welcome.

Questions regarding netsec and discussion related directly to netsec are welcome here, as is sharing tool links.

Rules & Guidelines

• Always maintain civil discourse. Be awesome to one another - moderator intervention will occur if necessary.
• Avoid NSFW content unless absolutely necessary. If used, mark it as being NSFW. If left unmarked, the comment will be removed entirely.
• If linking to classified content, mark it as such. If left unmarked, the comment will be removed entirely.
• Avoid use of memes. If you have something to say, say it with real words.
• All discussions and questions should directly relate to netsec.
• No tech support is to be requested or provided on r/netsec.

As always, the content & discussion guidelines should also be observed on r/netsec.

Feedback

Feedback and suggestions are welcome, but don't post it here. Please send it to the moderator inbox.

OpenBao engineers at ControlPlane have chained 4 vulnerabilities to show how under certain conditions, an OpenBao or Vault server can be completely compromised from an unauthenticated position. This is only the second RCE ever found in the Vault codebase.

The exploit is highly plausible in real-world environments, requiring only an unauthenticated entry path and a defined Raft snapshot policy to trigger a complete server compromise.

If you are impacted, upgrade as soon as possible to OpenBao 2.6.3 or 2.7.0

While OpenBao is fully patched, HashiCorp Vault remains exposed as of writing. Unfortunately, IBM's unwillingness to coordinate a mutual disclosure policy means Vault users currently lack an official mitigation

This is an article about the internals of Win32k (Windows's GUI subsystem) and their callouts, with the purpose of shedding light on a very undocumented and crucial subsystem in Windows :)

I work at Glow, and our Glow Labs research team just published this.

Developers asked their coding agents to share screenshots of their work for code review. Some agents decided on their own to create a brand-new public repo, usually under the developer's personal account, and put the screenshots there.

The team found 13k+ images across 300+ organizations, including a frontier AI lab and a Fortune 500 travel company. They show billing records, a financial firm's treasury console, and features weeks or months from release.

Since these repos weren't in the companies' own GitHub orgs, security teams never saw them.

Affected orgs have been notified. The writeup covers why the agents did this and where to look: https://glow.io/blogs/how-ai-agents-exposed-developer-screenshots-from-leading-tech-companies