# Fuzzing/Fuzz testing Fuzzing, or fuzz testing, is an automated software testing technique that supplies invalid, unexpected, or random inputs to programs and monitors them for crashes, vulnerabilities, or other undesirable behavior. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Sound Open Firmware 2.15 Released With AMD ACP 7.x Support, Intel UAOL DevFeed: [Sound Open Firmware 2.15 Released With AMD ACP 7.x Support, Intel UAOL]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-15T13:04:40Z Content type: release Language: en Sources: [Phoronix]() Topics: [Embedded Software Dev](), [Open Source](), [intel](), [Security](), [qemu](), [Xtensa](), [Fuzzing/Fuzz testing](), [POSIX](), [Testing]() Tags: [desktop-linux](), [driver](), [dsp](), [firmware](), [fuzzing](), [intel](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [posix](), [processor](), [qemu](), [security](), [testing](), [ubuntu-benchmarks](), [ubuntu-hardware](), [usb](), [xtensa]() ### AI overview Sound Open Firmware 2.15 adds user-space, memory-protected module execution, AMD ACP 7.x and NXP i.MX8MP support, Intel UAOL USB audio offload, testing targets, security hardening, and new audio processing modules. ### Source excerpt Sound Open Firmware as the open-source, vendor-independent audio DSP firmware stack and driver framework is out today with a new feature update... ## What to expect at the Zephyr Project Meetup (September 15, 2026) - Amsterdam, Netherlands DevFeed: [What to expect at the Zephyr Project Meetup (September 15, 2026) - Amsterdam, Netherlands]() Original publisher: [Read original article]() Author: Susan Remmert Published: 2026-09-09T05:00:04Z Content type: article Language: en Sources: [Zephyr Project]() Topics: [Zephyr RTOS](), [Embedded Systems](), [Open Source](), [Fuzzing/Fuzz testing](), [simulator](), [developer tooling]() Tags: [2026](), [blog](), [bugs](), [community](), [contributors](), [embedded](), [embedded-systems](), [event](), [events](), [firmware](), [fuzzing](), [harness](), [meetup](), [open-source](), [simulator](), [talk](), [technologies](), [tooling](), [tools](), [zephyr]() ### AI overview The Zephyr Project Meetup in Amsterdam on September 15, 2026, will bring together embedded developers, contributors, students, and engineers to exchange practical knowledge about Zephyr RTOS. The agenda includes talks on JetBrains' work with Zephyr, fuzzing Zephyr applications with AFL and Renode, and making hardware development easier with Schematik. ### Source excerpt What are developers in the Netherlands building with Zephyr? On September 15, the embedded community will meet in Amsterdam to exchange practical knowledge, discuss current work, and learn more about the Zephyr RTOS. The event is open to experienced contributors, first-time users, students, engineers, and anyone curious about open source embedded development. ## What to expect at the Zephyr Project Meetup (September 15, 2026) - Amsterdam, Netherlands DevFeed: [What to expect at the Zephyr Project Meetup (September 15, 2026) - Amsterdam, Netherlands]() Original publisher: [Read original article]() Author: Susan Remmert Published: 2026-09-09T05:00:04Z Content type: news Language: en Sources: [Zephyr Project]() Topics: [Zephyr RTOS](), [Embedded Systems](), [Fuzzing/Fuzz testing](), [Open Source]() Tags: [2026](), [blog](), [c](), [c-plus-plus](), [crashes](), [developer-tooling](), [embedded](), [embedded-systems](), [event](), [events](), [firmware](), [fuzzing](), [harness](), [jetbrains](), [meetup](), [memory-corruption](), [open-source](), [simulator](), [zephyr]() ### AI overview The Zephyr Project Meetup in Amsterdam on September 15, 2026, will bring together embedded developers, contributors, students, and engineers to share practical knowledge about Zephyr RTOS. The agenda includes talks on JetBrains' work with Zephyr, fuzzing Zephyr with AFL and Renode, and making hardware development easier with Schematik. ### Source excerpt What are developers in the Netherlands building with Zephyr? On September 15, the embedded community will meet in Amsterdam to exchange practical knowledge, discuss current work, and learn more about the Zephyr RTOS. The event is open to experienced contributors, first-time users, students, engineers, and anyone curious about open source embedded development. ## Stronger with every update: How we're making Chrome and the web safer in the AI Era DevFeed: [Stronger with every update: How we're making Chrome and the web safer in the AI Era]() Original publisher: [Read original article]() Author: Chrome Security Team Published: 2026-07-30T17:00:00Z Content type: article Language: en Sources: [Security]() Topics: [Chrome](), [Security](), [Vulnerabilities](), [Artificial Intelligence](), [Large Language Model](), [Fuzzing/Fuzz testing](), [Agent Harness](), [V8](), [JavaScript](), [interoperability](), [Resilience](), [Software]() Tags: [agent](), [ai](), [ai-models](), [bug](), [bugs](), [chrome](), [chrome-security](), [exploits](), [fuzzing](), [interoperability](), [javascript](), [none](), [resilience](), [security](), [vulnerabilities]() ### AI overview This article describes how Chrome's security teams use large language models, fuzzing, specialized research tools, and AI vulnerability-discovery agents to find and remediate security bugs more quickly. It highlights Big Sleep, an agent harness using Gemini, model interoperability, and a Chrome knowledge base built from CVEs and Git history. ### Source excerpt Video of Chrome logo turning into a shield ## Introducing Patch the Planet DevFeed: [Introducing Patch the Planet]() Original publisher: [Read original article]() Author: "Trail of Bits" Published: 2026-06-22T16:50:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Open Source](), [Security](), [Vulnerabilities](), [Maintainers](), [pull-requests](), [Fuzzing/Fuzz testing](), [GitHub](), [Cryptography](), [networking](), [cURL](), [Go Language]() Tags: [announcements](), [cryptography](), [fuzzing](), [github](), [github-actions](), [go](), [maintainers](), [networking](), [open-source](), [openai](), [patch-the-planet](), [pull-requests](), [security](), [supply-chain](), [vulnerabilities]() ### AI overview Patch the Planet pairs Trail of Bits engineers and open-source maintainers with frontier models to discover, triage, and fix security issues. Its first week produced hundreds of bugs, 64 pull requests, and 51 issues across 19 projects, with work also adding tests, fuzzing harnesses, CI security scanning, supply-chain tooling, correctness fixes, and features. ### Source excerpt What happens when you clear dozens of Trail of Bits engineers' schedules, pair them with every open-source maintainer they can contact, and unleash the latest frontier models like GPT-5.5-Cyber on critical open-source targets? Thanks to our partnership with OpenAI and its Daybreak initiative, we can report that the impact is hundreds of discovered bugs, 64 pull requests, and 51 issues filed across 19 projects (with many more still undergoing coordinated disclosure). That was just the first week of Patch the Planet. Frontier models like GPT-5.5-Cyber are producing a firehose of security findings, and already-stretched maintainers must sift through all of it to separate real vulnerabilities from plausible-sounding false positives. Patch the Planet is different: with our experts orchestrating and triaging findings, we handle the work of fixing and hardening the code alongside the people who maintain it. The first week of Patch the Planet covered 19 projects across cryptography, networking, language infrastructure, and software supply chain. Among these 19 projects were cURL, NATS, pyca, Sigstore, aiohttp, the Go project, freenginx, Python and python.org, urllib3, PyPI, SimpleX, Valkey, and RustCrypto. Over 30 projects have joined the initiative so far, and we're rapidly expanding it to include more; if you maintain an open-source project, apply to join! Live look at the Trail of Bits engineering teams Anyone can file an issue, flex, and walk away. We showed up with the patches: 37 are already merged, and many more are in flight. These merges go beyond just fixing bugs: we're adding new tests and fuzzing harnesses, CI security scanning, supply-chain tooling, correctness fixes, and features maintainers had been meaning to get to. The goal of Patch the Planet is to leave essential open-source projects measurably better off. We brought patches, not just bug reports We're reporting public findings on GitHub, including 64 total pull requests. We also filed 51 issues, 19 of w ## Choosing Values for Robust Tests DevFeed: [Choosing Values for Robust Tests]() Original publisher: [Read original article]() Author: Google Testing Bloggers (noreply@blogger.com) Published: 2026-06-04T12:47:00Z Content type: tutorial Language: en Sources: [Google Testing Blog]() Topics: [Testing](), [test](), [Code](), [implementation](), [bug](), [Fuzzing/Fuzz testing]() Tags: [article](), [bug](), [code](), [fuzzing](), [implementation](), [radion-khait](), [test](), [testing](), [tests](), [tott](), [unit-test]() ### AI overview The article explains how default-valued test inputs can let broken implementations pass unnoticed. It recommends non-default values, varied scenarios, boundary and special-case inputs, fuzzing, and distinct values for each parameter to improve test coverage and confidence. ### Source excerpt This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Radion Khait A test passes. Great! But does it really mean your code is working as expected? Not necessarily.Sometimes the values you choose in your tests can create a false sense of security, especially when dealing with default values. Consider this snippet of a simple map class and its corresponding unit test: Implementation Test void MyMap::insert(int key, int value) { // Oops! The map entry is default-initialized, // the second parameter is not used. internal_map_[key]; } TEST(MyMapTest, Insert) { MyMap my_map; my_map.insert(1, 0); // This passes! EXPECT_EQ(my_map.get(1), 0); } The test passes, but the insert method is broken! It never actually stores the value. The test only passes because the default value for an integer in the map (0) happens to match the value used in the test. When choosing test values, consider the following: Test with non-default values. Explicitly test with values different from the type's default (e.g., non-zero numbers, non-empty strings, enum values other than the one at index 0). This provides greater confidence that your code is actually using the provided input. TEST(MyMapTest, Insert) { MyMap my_map; my_map.insert(1, 5); // This test would fail and reveal the bug in // the implementation above: "Expected 5, got 0". EXPECT_EQ(my_map.get(1), 5); } Test multiple inputs that cover different scenarios, where it is reasonable to do so. Consider empty/missing/null values, numerical boundaries, and special cases that trigger complex logic. Try to cover all distinct code/logic paths. Consider using fuzzing to more thoroughly cover the input domain. Use different values for each input. This guarantees the code under test doesn't accidentally reuse a single input or switch their order. Parameterized testing can also help test a large variety of inputs with minimal code dupl ## New Logic for Programmers (and the future of this newsletter) DevFeed: [New Logic for Programmers (and the future of this newsletter)]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-05-06T17:03:46Z Content type: opinion Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [Formal methods](), [Fuzzing/Fuzz testing](), [Testing](), [Programming]() Tags: [developer](), [formal-methods](), [fuzzing](), [newsletter](), [release](), [testing](), [updates]() ### AI overview The author announces version 0.14 of Logic for Programmers, reports progress toward a 1.0 print edition, and shares plans to join Antithesis as a developer educator. The newsletter may shift toward software history and related topics, with its future publishing frequency uncertain. ### Source excerpt So first the immediate news: I just released version 0.14 of Logic for Programmers! This release is pretty similar to 0.13. There are a few rewrites but the vast majority of the changes are layout, copyediting, and technical editing. Full notes here. In related news, I've started doing test prints of the book: There's not a whole lot left to be done. I've gotta fix up some diagrams, do more formatting and proofreading, incorporate some fixes raised by readers, and make a website and back cover. After that, the book should be ready for 1.0. I'm aiming to have print copies purchasable by the end of June! Now the big news: starting August, I'll be a full-time employee of Antithesis, a generative testing platform. Officially my role is "developer educator", and I'll be tasked with making "property-based testing, fuzzing, fault injection, Hegel, Bombadil, and the Antithesis platform understandable to everyday engineers". So the same kind of work I do now, except with far more support and a matching 401(k). I already have three pages of topic ideas you have no idea how excited I am about this So how is this going to affect the newsletter? First, I want to make clear that this is not going to become an Antithesis newsletter. My Antithesis-related work is going to be on their official platforms. I do think one of the best ways to make a topic "understandable" is to write foundational material that's useful to all engineers, whether they're invested in the topic or not. I might share links to things I make along those lines, but they'll be just that, links. At the same time, the content of this newsletter will change a little. Property testing and fuzzing aren't the same as formal methods, but a lot of the foundations overlap, especially in how we think about properties and correctness. I don't know for sure yet, but I suspect that I'll start biasing this newsletter away from Antithesis related topics. So there will probably be less theoretic things like what does undecidabl ## Extending Ruzzy with LibAFL DevFeed: [Extending Ruzzy with LibAFL]() Original publisher: [Read original article]() Author: "Matt Schwager" Published: 2026-04-29T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [Fuzzing/Fuzz testing](), [Ruby](), [Rust](), [LLVM](), [Dockerfile](), [Linux](), [Security]() Tags: [application-security](), [complex-systems](), [developers](), [fuzzing](), [linux](), [llvm](), [ruby](), [rust](), [tool-release](), [tools]() ### AI overview The article describes adding LibAFL support to Ruzzy, a coverage-guided fuzzer for pure Ruby code and Ruby C extensions. It covers building LibAFL as a standalone library, integrating it through a Dockerfile, and investigating ELF and linker issues encountered during the integration. ### Source excerpt LibAFL is all the rage in the fuzzing community these days, especially with LLVM's libFuzzer being placed in maintenance mode. Written in Rust, LibAFL claims improved performance, modularity, state-of-the-art fuzzing techniques, and libFuzzer compatibility. For these reasons, I set out to add LibAFL support to Ruzzy, our coverage-guided fuzzer for pure Ruby code and Ruby C extensions. This gives Ruby developers and security researchers access to a more advanced and actively maintained fuzzing engine without changing how they write their fuzzing harnesses. Ruzzy was originally built on top of LLVM's libFuzzer, so using LibAFL's compatibility layer should be easy enough. However, digging around in the internals of complex systems is never quite as simple as it seems. In this post, I will investigate some of the deep plumbing inside these fuzzing engines, take a detour into executable and linkable format (ELF) files, and ultimately add LibAFL support to Ruzzy. Building with libafl_libfuzzer Ruzzy currently supports Linux, so I use a Dockerfile for development and for production fuzzing campaigns. To that end, using a similar Dockerfile for LibAFL support is the simplest integration point. LibAFL provides excellent documentation and build scripts to use it as a standalone library. We need to build LibAFL as a standalone library because Ruzzy uses libFuzzer as a library. Following along with the standalone libafl_libfuzzer documentation, and with the build.sh script in hand, we can build libFuzzer.a. This is the archive that will ultimately be linked into Ruzzy's C extension and used to fuzz our target. Here are the relevant lines from our new Dockerfile: # Install Rust nightly via rustup RUN wget -qO- https://sh.rustup.rs | sh -s -- \ -y \ --default-toolchain nightly \ --component llvm-tools ENV PATH="/root/.cargo/bin:${PATH}" # Clone LibAFL RUN git clone --depth 1 https://github.com/AFLplusplus/LibAFL /libafl # Build libFuzzer.a from LibAFL's libfuzzer runtime WORKDIR ## Introduction to Fuzzing ESP-IDF components DevFeed: [Introduction to Fuzzing ESP-IDF components]() Original publisher: [Read original article]() Author: John Lee Published: 2026-01-07T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [ESP-IDF](), [Fuzzing/Fuzz testing](), [Testing](), [Vulnerabilities](), [c/c++]() Tags: [blog](), [c-c-plus-plus](), [c-plus-plus](), [component](), [embedded](), [esp-idf](), [fuzzing](), [how-to](), [security](), [testing](), [vulnerabilities](), [vulnerability]() ### AI overview This article introduces fuzzing for ESP-IDF components and embedded libraries. It explains how to fuzz host-compiled code with sanitizers, compares black-box, grey-box, and white-box approaches, and outlines workflows using a basic mutator, AFL++, and protocol-focused harnesses. ### Source excerpt This article introduces fuzzing -- a technique for finding vulnerabilities -- and demonstrates practical workflows and lessons learned for ESP-IDF components and embedded libraries in general. ## exploits.club Weekly Newsletter 90 - Fuzzing Rust Subsystems, Pwn2Own Near Misses, Linux 1-Days, And More DevFeed: [exploits.club Weekly Newsletter 90 - Fuzzing Rust Subsystems, Pwn2Own Near Misses, Linux 1-Days, And More]() Original publisher: [Read original article]() Author: exploits.club Published: 2025-10-23T17:00:02Z Content type: news Language: en Sources: [exploits.club]() Topics: [Fuzzing/Fuzz testing](), [Rust](), [vulnerability](), [Security](), [Linux](), [network security](), [Kernel](), [Parsing]() Tags: [fuzzing](), [kernel](), [linux](), [network-security](), [parsing](), [rce](), [rust](), [security](), [vulnerability]() ### AI overview This weekly newsletter rounds up security research and developer-related resources, including fuzzing of Rust code in the Windows kernel, a WatchGuard Fireware OS vulnerability analysis, and a near-miss Pwn2Own printer exploit write-up. ### Source excerpt Good thing that absolutely no drama whatsoever took place for US vuln research firms this week...annnnnyways 👇 In Case You Missed It... OffensiveCon CFP - Closes March 1st, 2026 so let the procrastination begin! RE//Verse CFP - These need to be in by November 14th, so a bit less procrastinating. ## Trace similarity systems on top of ClickHouse to analyze crash stack traces from our CI DevFeed: [Trace similarity systems on top of ClickHouse to analyze crash stack traces from our CI]() Original publisher: [Read original article]() Author: Misha Shiryaev Published: 2025-09-24T12:46:35Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [ci](), [Traces](), [issue tracker](), [Fuzzing/Fuzz testing](), [FIRST]() Tags: [ci](), [clickhouse](), [crash-reporting](), [fuzzing](), [github](), [issue-tracker](), [logs](), [trace]() ### AI overview This article explains how to build a trace similarity system on top of ClickHouse to analyze crash stack traces from CI. It describes collecting crash reports, extracting stack frames, grouping similar traces, and creating or updating GitHub issues so teams can distinguish new bugs from known ones. ### Source excerpt Learn how our engineering team cut through noisy CI crash reports with a trace similarity system built on ClickHouse. ## exploits.club Weekly Newsletter 85 -Fuzzing KSMBD, Kernel-Hack-Drill, Vibe-Crashing, And More DevFeed: [exploits.club Weekly Newsletter 85 -Fuzzing KSMBD, Kernel-Hack-Drill, Vibe-Crashing, And More]() Original publisher: [Read original article]() Author: exploits.club Published: 2025-09-04T15:00:32Z Content type: article Language: en Sources: [exploits.club]() Topics: [Fuzzing/Fuzz testing](), [Linux Kernel](), [vulnerability](), [Security](), [race-condition](), [Exploit](), [Ubuntu]() Tags: [exploits](), [fuzzing](), [kernel](), [linux-kernel](), [race-condition](), [security](), [vulnerability]() ### AI overview The 85th exploits.club weekly newsletter highlights work on fuzzing improvements and vulnerability discovery in ksmbd, including 23 reported bugs. It also covers Kernel-Hack-Drill research on exploiting CVE-2024-50264, a Linux kernel socket race condition resulting in use-after-free, and related exploitation constraints. ### Source excerpt New idea - let AI submit a different, buzzwordy talks to every CFP. What could go wrong? Annnnnnnnyways 👇 In Case You Missed It... 0-day Hunting Strategy with Eugene "Spaceraccoon" Lim - Following the release of his recent No Starch Press book, @spaceraccoonsec will be on tomorrow' ## exploits.club Weekly Newsletter 80 - ITW Windows Bugs, Deterministic iOS Exploits, Pwn2Own Firefox Vulns, and More DevFeed: [exploits.club Weekly Newsletter 80 - ITW Windows Bugs, Deterministic iOS Exploits, Pwn2Own Firefox Vulns, and More]() Original publisher: [Read original article]() Author: exploits.club Published: 2025-07-24T15:21:15Z Content type: news Language: en Sources: [exploits.club]() Topics: [iOS](), [Firefox](), [Windows](), [bug](), [Exploit](), [Kernel](), [Fuzzing/Fuzz testing](), [IO](), [Mozilla]() Tags: [bugs](), [cve](), [exploits](), [firefox](), [fuzzing](), [ios](), [kernel](), [love](), [windows]() ### AI overview This issue of exploits.club Weekly Newsletter reviews recent security research and resources, including white-box fuzzing with AFL++, deterministic iOS kernel exploits extended to additional chipsets, an analysis of the Windows vulnerability CVE-2025-29824 and its use in the wild, and a Mozilla Firefox vulnerability discussed in connection with Pwn2Own. ### Source excerpt The Cameraman at that Coldplay concert pic.twitter.com/MHtqBxbwC6 -- Hater Report (@HaterReport_) July 18, 2025 Annnnnnnyways 👇 80 NEWSLETTERS 🎉 In Case You Missed It... Fuzzing 1001: Introductory white-box fuzzing with AFL++ - new course from OST2! Pwnie Nominees for 2025 - Released this week. Check them out!! Resources ## Xen Project 4.20: A Step Forward in Open Source Virtualization DevFeed: [Xen Project 4.20: A Step Forward in Open Source Virtualization]() Original publisher: [Read original article]() Author: Cody Zuschlag Published: 2025-03-11T13:30:38Z Content type: article Language: en Sources: [Blog - Xen Project]() Topics: [virtualization](), [Open Source](), [Security](), [Fuzzing/Fuzz testing](), [Optimization](), [Hardware](), [Cloud]() Tags: [2025](), [amd](), [announcements](), [architecture](), [cloud](), [fuzzing](), [hardware](), [intel](), [open-source](), [optimization](), [performance](), [release](), [releases](), [security](), [testing](), [virtualization](), [xen-4-20]() ### AI overview The article discusses the Xen Project's Xen 4.20 release as an open-source virtualization update. It highlights security improvements, including expanded MISRA C compliance, fuzzing, and UBSAN enabled by default, along with performance optimizations for page-table management, cache utilization, device passthrough, Intel CPUs, and AMD Zen 5. The release is presented as targeting cloud, enterprise, and embedded-system workloads. ### Source excerpt Xen 4.20 is here! 🚀 This release boosts security, performance, and architecture support, shaping the future of open-source virtualization. ## ClickHouse at FOSDEM 2025: talks, tech, and a community dinner DevFeed: [ClickHouse at FOSDEM 2025: talks, tech, and a community dinner]() Original publisher: [Read original article]() Author: Tyler Hannan Published: 2025-02-25T15:08:26Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [JSON](), [Fuzzing/Fuzz testing](), [Databases](), [Testing](), [Open Source]() Tags: [2025](), [clickhouse](), [community](), [databases](), [deep-dive](), [developers](), [fosdem](), [fuzzing](), [json](), [open-source](), [tech](), [testing]() ### AI overview A recap of ClickHouse's presence at FOSDEM 2025, covering a talk on its new powerful JSON data type and another on the challenges of fuzzing databases. The JSON presentation discusses column-oriented storage, dynamically changing structures, and fast querying of individual JSON paths. ### Source excerpt This year, ClickHouse made a strong showing at FOSDEM 2025, with several team members traveling to Belgium and multiple talks covering everything from powerful new JSON data types to the challenges of fuzzing databases. ## Concealing payloads in URL credentials DevFeed: [Concealing payloads in URL credentials]() Original publisher: [Read original article]() Author: Gareth Heyes Published: 2024-10-23T12:59:05Z Content type: article Language: en Sources: [PortSwigger Research]() Topics: [payload](), [browsers](), [Chrome](), [Firefox](), [Document Object Model (DOM)](), [Vulnerabilities](), [Fuzzing/Fuzz testing](), [Redirection]() Tags: [browsers](), [chrome](), [firefox](), [fuzzing](), [payload](), [redirection](), [vulnerabilities]() ### AI overview This article explains how payloads can be concealed in the credentials portion of URLs while remaining hidden from the address bars of Chrome and Firefox. It examines differences between document.URL and location, Firefox's handling of single quotes, and applications to DOM XSS, anchor credentials, redirection, and DOM clobbering. Safari discards URL credentials, so the described examples work only in Chrome and Firefox. ### Source excerpt Last year Johan Carlsson discovered you could conceal payloads inside the credentials part of the URL . This was fascinating to me especially because the payload is not actually visible in the URL in ## FuzzSlice: Separating real CVEs from fakes through fuzzing DevFeed: [FuzzSlice: Separating real CVEs from fakes through fuzzing]() Original publisher: [Read original article]() Published: 2024-09-19T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Fuzzing/Fuzz testing](), [Vulnerabilities](), [openssl](), [Security](), [Testing](), [supply-chain-security]() Tags: [cves](), [false-positives](), [fuzzing](), [openssl](), [security](), [software-supply-chain]() ### AI overview Chainguard Labs presents FuzzSlice, a fuzzing technique for determining whether CVEs are exploitable within an application context. In an evaluation of 18 OpenSSL CVEs, it classified 12 as exploitable and six as unreachable or false positives. ### Source excerpt Chainguard Labs explores FuzzSlice, a novel fuzzing technique, to improve vulnerability remediation by distinguishing exploitable CVEs from false positives. ## Introducing Bettercap 2.4.0: CAN-Bus Hacking, WiFi Bruteforcing and Builtin Web UI DevFeed: [Introducing Bettercap 2.4.0: CAN-Bus Hacking, WiFi Bruteforcing and Builtin Web UI]() Original publisher: [Read original article]() Author: Simone Margaritelli Published: 2024-09-13T10:46:25Z Content type: release Language: en Sources: [evilsocket]() Topics: [Hacking](), [Security](), [Fuzzing/Fuzz testing](), [Protocol (disambiguation)](), [Hardware](), [ui]() Tags: [automotive-security](), [bettercap](), [can-bus](), [canbus](), [car](), [car-hacking](), [cybersecurity](), [features](), [fuzzing](), [hacking](), [hardware](), [ics](), [industrial](), [industrial-control](), [offensive-tools](), [protocol](), [release](), [socketcan](), [webui](), [wifi](), [wifi-bruteforcing](), [wireless-security]() ### AI overview The article announces bettercap 2.4.0, a major release that adds functionality for car and industrial control system security research. It describes a new CAN-bus module for reading, replaying, injecting, and fuzzing frames, parsing frames with DBC files, and detecting ECUs, alongside other new features and fixes. ### Source excerpt I'm happy to announce, after quite some time, the new bettercap 2.4.0 major release. Other than including a plethora of long due fixes (additionally to what the recent 2.33.0 already fixed), it also packs a few new functionalities that extend its reach to car and industrial control system hacking. It'll possibly take me some time to update the documentation on the official website so I'm here today to write a bit about the new features. Also remember that you can use the help, help ui, help can and help wifi commands to check all the new options and added functionalities. ## Mastering Nixpkgs Overlays: Techniques and Best Practice DevFeed: [Mastering Nixpkgs Overlays: Techniques and Best Practice]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2024-08-01T00:00:00Z Content type: tutorial Language: en Sources: [Nixcademy Blog]() Topics: [Nix](), [function](), [monorepo](), [Open Source](), [systems](), [Fuzzing/Fuzz testing](), [Testing]() Tags: [function](), [fuzzing](), [how-to](), [monorepo](), [open-source](), [patches](), [systems](), [techniques](), [testing]() ### AI overview This tutorial explains how Nixpkgs overlays help compose package collections and build different package or system-image variants. It covers the problems overlays solve, how to apply them to package trees and system images, and positive and negative examples. ### Source excerpt Overlays in Nixpkgs are a powerful mechanism, but they are also complex to grasp. We tell you everything you need to know about Nixpkgs overlays. ## Snapshots for IPC Fuzzing DevFeed: [Snapshots for IPC Fuzzing]() Original publisher: [Read original article]() Author: Christian Holler Published: 2024-06-27T16:18:49Z Content type: article Language: en Sources: [Mozilla Hacks - the Web developer blog]() Topics: [Fuzzing/Fuzz testing](), [Firefox](), [out-of-process](), [Security](), [Vulnerabilities](), [Testing]() Tags: [featured-article](), [firefox](), [fuzzing](), [ipc](), [memory-safety](), [mozilla](), [open-source](), [processes](), [security](), [snapshots](), [ssecurity](), [testing](), [vulnerabilities]() ### AI overview This article explains how Firefox uses process separation and IPC to isolate lower-privilege content processes from the privileged parent process. It introduces snapshot fuzzing, a method for rewinding application state to make testing critical IPC interfaces more practical by avoiding costly browser restarts and reducing iteration latency. ### Source excerpt Process separation remains one of the most important parts of the Firefox security model and securing our IPC (Inter-Process Communication) interfaces is crucial to keep privileges in the different processes separated. We take a more detailed look at our newest tool for finding vulnerabilities in these interfaces - snapshot fuzzing. The post Snapshots for IPC Fuzzing appeared first on Mozilla Hacks - the Web developer blog. ## Secured #6 - Writing Robust C - Best Practices for Finding and Preventing Vulnerabilities DevFeed: [Secured #6 - Writing Robust C - Best Practices for Finding and Preventing Vulnerabilities]() Original publisher: [Read original article]() Author: Justin Traglia Published: 2023-11-02T00:00:00Z Content type: article Language: en Sources: [Ethereum Foundation Blog]() Topics: [Ethereum](), [C](), [Fuzzing/Fuzz testing](), [Library](), [Testing](), [Security](), [LLVM](), [make]() Tags: [c](), [ethereum](), [fuzzing](), [library](), [llvm](), [make](), [research-development](), [security](), [testing](), [vulnerabilities]() ### AI overview The article explains how Ethereum developers secured the c-kzg-4844 C library used by clients to compute and verify KZG commitments for EIP-4844. It covers LibFuzzer-based testing, differential fuzzing against go-kzg-4844, and coverage analysis with LLVM tools. ### Source excerpt For EIP-4844, Ethereum clients need the ability to compute and verify KZG commitments. Rather than each client rolling their own crypto, researchers and developers came together to write c-kzg-4844, a relatively small C library with bindings for higher-level languages. The idea was to create a robust and efficient cryptographic library... ## What the fuzz? Better coding through randomized testing DevFeed: [What the fuzz? Better coding through randomized testing]() Original publisher: [Read original article]() Published: 2023-03-13T00:00:00Z Content type: opinion Language: en Sources: [Chainguard: Unchained]() Topics: [Testing](), [Fuzzing/Fuzz testing](), [Test-driven development](), [Software Engineering]() Tags: [code-testing](), [debug](), [fuzzing](), [python](), [research](), [software-development](), [software-testing](), [techniques](), [test](), [testing]() ### AI overview This Chainguard article explains how randomized testing and fuzzing can help developers find complicated software bugs. It presents randomized testing as complementary to test-driven development and discusses choosing testing techniques for the right applications. ### Source excerpt Why do we test our code? Find out in this Chainguard post on the benefits of randomized testing and fuzzing practices. ## High-Throughput, Formal-Methods-Assisted Fuzzing for LLVM DevFeed: [High-Throughput, Formal-Methods-Assisted Fuzzing for LLVM]() Original publisher: [Read original article]() Author: regehr Published: 2022-05-31T14:56:41Z Content type: article Language: en Sources: [Embedded in Academia]() Topics: [Fuzzing/Fuzz testing](), [LLVM](), [Formal methods](), [Testing](), [bug]() Tags: [bug](), [formal-methods](), [fuzzing](), [llvm](), [mutation](), [testing](), [uncategorized]() ### AI overview The article describes mutation-based fuzzing for LLVM optimization passes, combining a custom LLVM IR mutator with the formal methods tool Alive2 to check whether optimizations are correct or buggy. The authors report that generic mutation with radamsa produced mostly invalid or semantically unchanged tests and found no bugs after several days, motivating a structure-aware mutator that preserves LLVM IR invariants. ### Source excerpt [This piece is coauthored by Yuyou Fan and John Regehr] Mutation-based fuzzing is based on the idea that new, bug-triggering inputs can often be created by randomly modifying existing, non-bug-triggering inputs. For example, if we wanted to find bugs in a PDF reader, we could grab a bunch of PDF files off the web, mutate [...] ## Kiln Testnet Merge Transition Reveals Client Bugs as Ethereum Testing Continues DevFeed: [Kiln Testnet Merge Transition Reveals Client Bugs as Ethereum Testing Continues]() Original publisher: [Read original article]() Author: Danny Ryan Published: 2022-03-23T00:00:00Z Content type: article Language: en Sources: [Ethereum Foundation Blog]() Topics: [Blockchain](), [Testing](), [Security](), [Fuzzing/Fuzz testing](), [Network]() Tags: [blockchain](), [encoding](), [fuzzing](), [network](), [research-development](), [security](), [testing]() ### AI overview The article reports that Ethereum's Kiln testnet completed its transition from proof of work to proof of stake. It describes encoding and synchronization errors during the transition and outlines expanded testing, fuzzing, code review, and security efforts ahead of public testnet upgrades. ### Source excerpt tl;dr Kiln🧱🔥 is up, check it out #TestingTheMerge is in full swing. Do your part, get involved!... [Next page]()