IBM Langflow SSRF bypass, Woodpecker CI approval spoofing, and a 64-bit DH key in UltraVNC

Woodpecker CI before 3.15.0 checks the approval-bypass allowlist against the git commit author name, which comes straight from the webhook payload. When using the GitLab forge driver, that name is whatever the attacker typed into their git config, not something GitLab verifies. Anyone who can open a merge request from a fork can set their commit author name to match an approved user, skip the approval gate entirely, and run arbitrary pipeline steps on your Woodpecker agent, including exfiltrating CI secrets. Gitea, Forgejo, GitHub, and Bitbucket drivers are not affected because they pull the author from a forge-validated identity.

Affected estate

Teams running Woodpecker CI before 3.15.0 with the GitLab forge driver and fork-approval workflows enabled

How to check

Check `woodpecker-server --version` and review your server config for `WOODPECKER_FORGE=gitlab` and any `WOODPECKER_APPROVAL_ALLOWED_USERS` entries.

Included because

approval bypass; CI secret exfiltration; attacker-controlled input trusted as identity; CVSS 8.1

Action

Upgrade Woodpecker to 3.15.0+. Audit recent pipeline runs from fork MRs for unexpected approvals or secret access.

Why it matters

An attacker with fork access can bypass approval, run arbitrary code on your CI agent, and steal every secret exposed to that pipeline.

A crafted OpenAPI document with a circular schema reference can crash any .NET application that uses the OpenAPI.NET SDK to parse it. The parser recurses until it hits a stack overflow, which kills the process outright. If your app or API gateway parses untrusted OpenAPI specs (user-uploaded docs, third-party API imports), this is a straightforward denial-of-service vector. Both JSON and YAML parsing paths are affected.

Affected estate

.NET developers and platform teams using Microsoft.OpenApi (OpenAPI.NET) versions 2.0.0-preview11 through 2.7.4, or 3.x through 3.5.3

How to check

Run `dotnet list package` in your project directory and look for Microsoft.OpenApi. Check if the version falls in the affected range.

Included because

denial of service; process crash; common SDK in .NET API tooling; CVSS 7.5

Action

Update to Microsoft.OpenApi 2.7.5 or 3.5.4 via NuGet and redeploy affected services.

Why it matters

A tiny malicious OpenAPI document can crash your service process, causing a full outage with no recovery except a restart.

GLib's D-Bus introspection XML parser (g_dbus_node_info_new_for_xml) mishandles a <node> element nested inside elements like <method> or <signal>. Feeding it malformed XML triggers an unsigned integer overflow followed by an out-of-bounds read, which crashes the process. Any application that parses untrusted D-Bus introspection XML is vulnerable to denial of service.

Affected estate

Linux sysadmins and developers running applications that use GLib's D-Bus introspection XML parser, particularly services that accept introspection data from untrusted sources

How to check

Check your GLib version with `pkg-config --modversion glib-2.0` or query your package manager (e.g., `dpkg -l libglib2.0-0`).

Included because

denial of service; out-of-bounds read; GLib is a foundational library on Linux; CVSS 7.5

Action

Apply the GLib update from your distro's security repo. Restart affected D-Bus services after updating.

Why it matters

Malformed D-Bus XML input can crash any process using this GLib parser, causing service outages on systems that handle untrusted introspection data.

UltraVNC through 1.8.2.2 uses laughably weak crypto for its MS-Logon II authentication. The Diffie-Hellman key exchange uses a prime that fits in 64 bits, which an attacker can break in under a second. On top of that, the private exponent comes from a PRNG seeded with time(NULL) and carrying roughly 31 bits of state, making it recoverable in under a minute. Anyone who can sniff or record the VNC handshake (or sit in a man-in-the-middle position) can decrypt the username and password in plaintext. MS-Logon III (X25519 + AES-256-GCM) is not affected.

Affected estate

Anyone running UltraVNC through 1.8.2.2 with MS-Logon II authentication enabled, especially over untrusted or flat networks

How to check

Check UltraVNC version in Help > About. Review the server configuration to see if MS-Logon II is the active authentication scheme (look for the MsLogonIIAuth setting in ultravnc.ini).

Included because

credential disclosure; passive network attack; broken cryptography; common remote access tool; CVSS 7.4

Action

Switch to MS-Logon III authentication immediately. If that's not possible, ensure all VNC connections are tunneled through a VPN or SSH. Upgrade UltraVNC when a patched version is released.

Why it matters

A passive network observer can recover VNC login credentials in seconds, giving them full remote access to every system using MS-Logon II authentication.