What if a VNC server could make your viewer believe it had a ~4 GB framebuffer… while actually allocating only 128 KB?

That’s the core of this TightVNC vulnerability.

A malicious server can announce a crafted 32768 × 32769 screen at 32bpp, causing the framebuffer size calculation to overflow. The allocation wraps down to 128 KB, but the viewer continues using the original, much larger dimensions when calculating pixel writes.

The result is a server-controlled out-of-bounds write in the viewer.

It’s a good example of how a relatively small integer-overflow mistake can become a powerful memory-corruption primitive when different parts of the application disagree about the true size of a buffer.

I've spent the last four days investigating and fine-tuning a remote DoS against the Linux kernel's TIPC implementation. A remote peer-state transition can trigger a NULL pointer dereference in TIPC's name-distribution path, causing a kernel panic and taking down the host.

I've really enjoyed digging into this, and I'm pretty happy with how the research turned out.

Egov.Integrations.MPass.Saml, the ASP.NET Core handler that relying parties use to verify MPass SAML 2.0 responses, verified signatures like this in every version before 10.0.4:

signedXml.LoadXml(signatureElement); return signedXml.CheckSignature(publicCertificate, verifySignatureOnly: true);

CheckSignature confirms that the references in SignedInfo are validly signed. Nothing tied a signed reference to the response root the relying party then reads, so anyone holding one validly signed MPass message could relocate the signed element, put chosen assertion content at the root, and still pass verification. The result is authentication as an arbitrary user. Version 10.0.4 adds the missing check: exactly one reference, and its URI must equal the root element ID.

• Weakness: CWE-347 (Improper Verification of Cryptographic Signature)
• Attack pattern: CAPEC-475 (Signature Spoofing by Improper Validation)
• Affected: 8.0.53 to 8.0.56 and 10.0.2
• Fixed: 10.0.4 and 10.0.5

Serghei Zagaiciuc found and publicly disclosed the flaw. I confirmed the affected range and the fix by decompiling the published packages. I have submitted a CVE ID request through the MITRE CNA of Last Resort form; so far it has a tracking number, CAN-2026-2041077, and no CVE ID has been assigned yet. No exploit is published.

• Advisory with the decompiled diff: https://www.masiutin.net/mpass-saml-xml-signature-wrapping.html
• Original disclosure: https://www.linkedin.com/posts/sergheizagaiciuc_moldova-had-a-major-cybersecurity-blunder-activity-7520870795661897730-j8_I

In Godot 4.0 and later, in games using the engine's standard spawning setup, a peer with authority over the relevant spawner - by default the server the client joins - can crash that client with one crafted packet.

ElectroNG is now free and open source.

I've recently released a blog covering how I discovered a new Kerberos delegation abuse path!

By combining Elad Shamir's Reflective RBCD with James Forshaw's U2U sacrificial user technique, Constrained Delegation without Protocol Transition can now be abused against SPN-less accounts. I also had to add S4U2Proxy + U2U support to Impacket to get this working. :)

Blog: https://hunio.org/security/abusing-constrained-delegation-without-protocol-transition-against-spn-less-accounts

Impacket PR: https://github.com/fortra/impacket/pull/2324