FuzzingLabs

🇨🇭 Proud to announce that FuzzingLabs has been selected for Tech4Trust Season 8! #Tech4Trust is the flagship Swiss acceleration program run by Trust Valley, dedicated to solutions strengthening digital trust, cybersecurity and emerging technologies. Applications are reviewed by an Advisory Board of 52 members from the public sector, private industry, academia, scaleups and Tech4Trust alumni, so being picked means a lot to our team.   Over the next 9 months, from Trust Valley Days on September 23-24, 2026 to Demo Day on June 10, 2027, we'll go through roadshows and meetings with corporate leaders and investors in hubs like Zurich, Lausanne, Geneva, Singapore, the UK, France and San Francisco.   For us, it's a great opportunity to bring FuzzForge, our AI-powered continuous offensive validation platform, to Swiss and international players who need to secure critical software, connected products and embedded systems at scale. Huge thanks to the Trust Valley team for the trust. See you at the booth today! 🚀 #Tech4Trust #TrustValley #Cybersecurity #Fuzzing #VulnerabilityResearch #FuzzForge #Switzerland

A file in the #Linux kernel with 0% Syzbot coverage is an invitation. That's how our team at FuzzingLabs ended up in batman-adv, the mesh networking subsystem (B.A.T.M.A.N. = Better Approach To Mobile Ad hoc Networking). Its routing.c had never been touched by Syzbot's coverage. So we went in. What it took: → Wiring Syzkaller to the Ethernet frame reception path via TUN/TAP + syz_emit_ethernet → Patching the executor to bring up the bat0 interface correctly → Writing a Syzlang grammar for batman-adv packets from scratch, none existed, so we derived it from batadv_packet.h What came out: 1. A 16-bit signed integer overflow in OGM fragmentation (buff_pos overflows on large frames while being checked against a 32-bit length), reported to the maintainers, patch now merged in mainline. 2. A use-after-free race in the throughput meter when the interface is deleted mid-session. 3. An integer truncation in the TT TVLV unicast handler, flex_array_size() returns a size_t, assigned to a u16, leading to an out-of-bounds read. The lesson isn't exotic: coverage dashboards are public, and the gaps in them are where the bugs still live. The hard part is the harness, not the target. Full write-up link in comment. #LinuxKernel #Fuzzing #Syzkaller #VulnerabilityResearch #OffensiveSecurity

Fuzzinglabs is joining #SEAstart, the GICAN accelerator for the French naval industry. We build offensive security for embedded and naval systems allowing security team to find the flaws an attacker would exploit, before they do. Why it matters: a modern naval platform runs on hundreds of embedded and OT systems, and most of them were never built to be attacked. Our recent maritime research made that concrete with 6 CVEs across the full navigation stack: GNSS/RTK positioning (RTKLIB), AIS traffic (libais), and the NMEA 2000 onboard bus (CANBoat), several are exploitable without authentication. With #FuzzForge, we bring that same offensive validation continuously to firmware and embedded systems, instead of one-off audits. Joining #SEAstart puts us shoulder to shoulder with the shipbuilders and integrators who defend these platforms every day. Grateful to GICAN and the SEAstart team for the trust! great to present alongside the ecosystem at the GICAN General Assembly last week. We're now looking for 2–3 naval design partners, primes or integrators with a mature security team, to run a PoC on real embedded firmware. If that's you, let's talk! #Cybersecurity #NavalDefense #OffensiveSecurity #GICAN #SEAstart #EmbeddedSecurity #Maritime #FrenchTech

Cryptography on embedded devices: the hard part isn't picking the algorithm. When people talk about "crypto on embedded," they jump straight to "AES or Ascon?" But choosing a primitive is often the luxury, not the challenge. The real questions come before that: → Where do the keys actually live? → Can the chip give you a decent random number… or any at all? → Can it reliably persist a counter across reboots? (Hello, AES-GCM nonces.) → How many bytes are you even allowed to put on the wire? → And crucially: does the chip already ship an accelerator you're expected to use, whether you like it or not? In our new 101 guide, we walk through what modern embedded hardware really gives you: 🔹 Randomness engines: why "if you can't trust the platform's RNG, don't depend on it," and how deterministic ECDSA / EdDSA and AES-SIV buy you nonce-misuse resistance. 🔹 AES acceleration: the difference between instruction-set extensions (AES-NI, ARMv8 Crypto, RISC-V scalar/vector) and dedicated accelerator blocks like the ones in Apple's Secure Enclave. 🔹 Why 3DES is still alive in 2026: spoiler - it's not a technical limitation, it's payment infrastructure and the cost of replacement. 🔹 Ascon: NIST's lightweight standard (finalized August 2025) and when it beats AES on devices with no accelerator. The through-line: cost is the constraint behind every constraint. That single fact explains why a 1998-era cipher still sits in payment terminals today. A practical starting point for anyone building or auditing security on constrained hardware. 📖 Blogpost link in comment. #EmbeddedSecurity #Cryptography #IoTSecurity #HardwareSecurity #FuzzingLabs

Proud to see FuzzingLabs featured in the 2026 French Cybersecurity Innovation Startup Radar by Wavestone & Bpifrance 🇫🇷 8th edition, 234 startups mapped and we're on it, in the Vulnerabilities category. This year's radar makes one thing clear: agentic AI and offensive automation are reshaping cybersecurity. That's exactly the bet we've been building on FuzzForge, our orchestration platform for specialized AI agents delivering continuous offensive validation on firmware, binaries and embedded systems. Finding the real vulnerabilities in the code that runs critical and connected infrastructure isn't a demo. It's the job. Thanks to the Wavestone and Bpifrance teams for the work behind this radar. Full study 👇 https://lnkd.in/ewF8S2pu Thanks Gerome Billois Samuel Mangin Sébastien Montusclat #Cybersecurity #Fuzzing #OffensiveSecurity #EmbeddedSecurity #FrenchTech

That's a wrap on VivaTech 2026 🚀 One full day talking embedded security with builders, PSIRT leads, partners, and investors across automotive, industrial, and defense. The energy was incredible and the conversations were sharp, thank you to everyone who stopped by. 🙏 For those we didn't get to meet, here's what we do at FuzzingLabs: Embedded device makers can't easily prove vulnerability exploitability, yet that's exactly what the EU Cyber Resilience Act now demands. FuzzForge closes that gap: AI agents running continuous offensive validation, delivering reproducible exploit proofs your security team can actually trust and act on. Less noise, faster triage, real evidence for compliance. We're going to market and actively talking to clients and investors. If firmware, binary, or embedded security is on your radar, let's talk. 👇 Huge thanks to the team for making it happen! #VivaTech #Cybersecurity #EmbeddedSecurity #CyberResilienceAct #OffensiveSecurity #FuzzForge

🚀 We’re at VivaTech today - come find us! FuzzingLabs is exhibiting at stand 2B16 (005), 2nd floor. If you care about embedded security and embedded systems security, let’s talk. Embedded device makers can’t prove vulnerability exploitability the way the EU Cyber Resilience Act now demands and that’s exactly the gap FuzzForge closes: AI agents running continuous offensive validation, with reproducible exploit proofs. We work with PSIRT teams across automotive, industrial, and defense. Whether you’re a builder facing CRA deadlines, a potential client, or just want to geek out on firmware and binary security! stop by stand 2B16, 2nd floor. 👋 #VivaTech #Cybersecurity #EmbeddedSecurity #CyberResilienceAct #OffensiveSecurity #FuzzForge

🛰️ Spoofing the Sky: we broke RTKLIB, the brain behind centimeter-accurate GPS used in some maritime systems. Plain GPS gets you within a few meters. Good enough for a phone, useless for landing a drone on a moving boat or keeping a tractor in a 2 cm furrow. That precision comes from RTK and RTKLIB is the open-source engine most of the industry leans on for it: drones, autonomous vessels, self-driving stacks, survey gear, national CORS networks. Its decoders are the front door. They parse correction streams (RTCM3 over NTRIP) and observation files (RINEX) before a single coordinate is ever computed and that front door was never hardened against hostile input. We found 4 memory-corruption bugs: → 1 out-of-bounds write in the antenna-descriptor decoder (decode_type1033) → 3 out-of-bounds reads across the SSR, epoch-count and observation-code paths No authentication. No handshake. An attacker just has to sit upstream of the antenna a rogue NTRIP caster, a MITM'd stream, or a single booby-trapped RINEX file. And because RTKLIB is permissively licensed and forked everywhere, the same flaws ride quietly into closed firmware that never even says the word "RTKLIB." What "the decoder crashed" actually means once it's bolted onto something with mass and momentum: a grounding risk in a harbor, a dropped localization input across a vehicle fleet, the difference between a landing and a flyaway. All four reported upstream under coordinated disclosure (RTKLIB #796–799). The GNSS stack deserves the same adversarial scrutiny we've spent two decades giving browsers and kernels. We're just getting started. 👇 🔗 https://lnkd.in/eppFpXPn #GNSS #RTK #cybersecurity #vulnerabilityresearch #fuzzing #embedded #automotive #drones