<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:media="http://search.yahoo.com/mrss/"><channel><title>637th Research Lab</title><description>Security research write-ups: reverse-engineering, vulnerability discovery, and the methodology behind them.</description><link>https://y637f9qq2x.com/</link><language>en</language><lastBuildDate>Sun, 16 Aug 2026 00:00:00 GMT</lastBuildDate><generator>Astro v7.1.3 + @astrojs/rss v4.0.19</generator><copyright>© 2026 Kazuma Matsumoto</copyright><atom:author><atom:name>Kazuma Matsumoto</atom:name><atom:uri>https://y637f9qq2x.com/whoami/</atom:uri></atom:author><image><url>https://y637f9qq2x.com/assets/img/favicons/favicon-96x96-v2.png</url><title>637th Research Lab</title><link>https://y637f9qq2x.com/</link><width>96</width><height>96</height></image><atom:link href="https://y637f9qq2x.com/rss.xml" rel="self" type="application/rss+xml"/><item><title>CVE-2026-5917: OS Command Injection in libgit2’s SSH Backend</title><link>https://y637f9qq2x.com/posts/cve-2026-5917/</link><guid isPermaLink="true">https://y637f9qq2x.com/posts/cve-2026-5917/</guid><description>libgit2’s libssh2 backend quotes the repository path but escapes nothing. One quote in the path can run commands on an SSH server that gives a shell.</description><pubDate>Sun, 16 Aug 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;libgit2’s libssh2 backend quotes the repository path but escapes nothing. One quote in the path can run commands on an SSH server that gives a shell.&lt;/p&gt;&lt;p&gt;Disclosure. CVE-2026-5917 was assigned by VulnCheck, which published its advisory on 11 August 2026. It is fixed in libgit2 v1.9.7 and v1.8.7, both released on 13 August 2026. If you build libgit2 with the libssh2 SSH backend, move to one of those. Everything I ran for this post ran against a local SSH server inside a WSL2 virtual machine on my own laptop. No proof-of-concept source code is included, and nothing here was tested against any hosted Git service. To fetch a repository over SSH, a Git client has to ask the server for it. It opens an SSH session and sends one line of text, which looks like this: The server runs that line and streams the repository back. The single quotes are there so that a path containing spaces still arrives as one argument. libgit2 builds that line by joining pieces of text together.&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://y637f9qq2x.com/posts/cve-2026-5917/&quot;&gt;Read the full post&lt;/a&gt; — 34 min read.&lt;/p&gt;</content:encoded><atom:updated>2026-09-13T00:00:00.000Z</atom:updated><dc:creator>Kazuma Matsumoto</dc:creator><media:thumbnail url="https://y637f9qq2x.com/og/cve-2026-5917.png" width="1200" height="630"/><category>cve</category><category>command-injection</category><category>libgit2</category><category>ssh</category><category>vulnerability-research</category></item><item><title>CVE-2026-5857: Remote Code Execution in Contiki-NG’s MQTT Client</title><link>https://y637f9qq2x.com/posts/cve-2026-5857/</link><guid isPermaLink="true">https://y637f9qq2x.com/posts/cve-2026-5857/</guid><description>A malicious broker splits one PUBLISH across two TCP segments, skips a bounds check that is present and correct, and overwrites a function pointer.</description><pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;A malicious broker splits one PUBLISH across two TCP segments, skips a bounds check that is present and correct, and overwrites a function pointer.&lt;/p&gt;&lt;p&gt;This post documents CVE-2026-5857, an out-of-bounds write (a bug where a program writes past the end of a memory buffer and changes whatever data is stored after it) in the MQTT client of Contiki-NG, an operating system for small networked devices. I reported it, and VulnCheck assigned it as the CVE Numbering Authority. The interesting part is not that a bounds check was missing. A bounds check is present, it is written correctly, and it still does not stop the overflow. The check compares the incoming topic length against the buffer size, exactly as you would want. But the line immediately above it records that the length has been read. When the topic is too long, the check rejects it and the function returns without undoing that record. The next time the function runs, the record still says the length was handled.&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://y637f9qq2x.com/posts/cve-2026-5857/&quot;&gt;Read the full post&lt;/a&gt; — 28 min read.&lt;/p&gt;</content:encoded><atom:updated>2026-09-12T00:00:00.000Z</atom:updated><dc:creator>Kazuma Matsumoto</dc:creator><media:thumbnail url="https://y637f9qq2x.com/og/cve-2026-5857.png" width="1200" height="630"/><category>cve</category><category>buffer-overflow</category><category>contiki-ng</category><category>iot</category><category>vulnerability-research</category></item><item><title>CVE-2026-18759: Privilege Escalation in ASUSTOR Backup Plan</title><link>https://y637f9qq2x.com/posts/asustor-lpe/</link><guid isPermaLink="true">https://y637f9qq2x.com/posts/asustor-lpe/</guid><description>ASUSTOR Backup Plan’s Windows service ABP_VSS_Service treats encryption as authentication and checks paths with a substring test. Standard user to SYSTEM.</description><pubDate>Wed, 12 Aug 2026 01:00:00 GMT</pubDate><content:encoded>&lt;p&gt;ASUSTOR Backup Plan’s Windows service ABP_VSS_Service treats encryption as authentication and checks paths with a substring test. Standard user to SYSTEM.&lt;/p&gt;&lt;p&gt;A note on disclosure. This finding was disclosed to ASUSTOR and is tracked as CVE-2026-18759 (ASUSTOR advisory AS-2026-021). It is fixed: upgrade Backup Plan to 2.0.8.7230 or later, and EZ Sync to 1.1.1.7230 or later. The advisory rates it CVSS v4.0 8.5 and covers both products. This write-up is published with the vendor’s agreement. Two patterns show up over and over in Windows software that runs with elevated privileges. The first: treating “this message is encrypted” as proof that “this message is legitimate.” Encryption protects secrecy; it does not prove identity. The full argument is in §1.4, but the one-line version is enough: “it decrypts” proves only that the sender had the key. The second: guarding a file path with a substring check instead of a containment check.&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://y637f9qq2x.com/posts/asustor-lpe/&quot;&gt;Read the full post&lt;/a&gt; — 28 min read.&lt;/p&gt;</content:encoded><atom:updated>2026-09-12T15:00:00.000Z</atom:updated><dc:creator>Kazuma Matsumoto</dc:creator><media:thumbnail url="https://y637f9qq2x.com/og/asustor-lpe.png" width="1200" height="630"/><category>cve</category><category>windows</category><category>lpe</category><category>ipc</category><category>case-study</category><category>vulnerability-research</category></item><item><title>Claude Cowork Boots Its Sandbox From a Folder You Can Rewrite</title><link>https://y637f9qq2x.com/posts/cowork-boot-trust/</link><guid isPermaLink="true">https://y637f9qq2x.com/posts/cowork-boot-trust/</guid><description>Cowork boots a Hyper-V VM from user-writable AppData with no hash or signature check. Replace the initrd; SYSTEM boots it. Anthropic: by design.</description><pubDate>Tue, 21 Jul 2026 01:00:00 GMT</pubDate><content:encoded>&lt;p&gt;Cowork boots a Hyper-V VM from user-writable AppData with no hash or signature check. Replace the initrd; SYSTEM boots it. Anthropic: by design.&lt;/p&gt;&lt;p&gt;Disclosure. This finding was reported to Anthropic via HackerOne. Anthropic reviewed the submission, determined it is working as designed within its threat model, and has given permission to publish this write-up. This post documents a finding in Claude Desktop’s Cowork feature — the sandbox that runs AI-generated code inside a Hyper-V virtual machine (VM) on Windows. The finding is simple to state: the VM’s boot images (the Linux kernel, the initial ramdisk, and the root filesystem) are stored in a folder the user has full control over, and the service that boots the VM runs as SYSTEM — the most privileged account on Windows — yet never checks whether those images have been tampered with.&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://y637f9qq2x.com/posts/cowork-boot-trust/&quot;&gt;Read the full post&lt;/a&gt; — 21 min read.&lt;/p&gt;</content:encoded><atom:updated>2026-09-13T00:00:00.000Z</atom:updated><dc:creator>Kazuma Matsumoto</dc:creator><media:thumbnail url="https://y637f9qq2x.com/og/cowork-boot-trust.png" width="1200" height="630"/><category>windows</category><category>trust-model</category><category>vm-security</category><category>claude</category><category>not-vulns</category></item><item><title>U-Boot TCP/NFS Vulnerabilities: Integer Underflow and Buffer Overflow in the World’s Most Popular Bootloader</title><link>https://y637f9qq2x.com/posts/u-boot-tcp-nfs-vulns/</link><guid isPermaLink="true">https://y637f9qq2x.com/posts/u-boot-tcp-nfs-vulns/</guid><description>Three CVEs in U-Boot’s network stack: one unchecked TCP header length that gives two reads past the packet, and an NFS path overflow past a 2048-byte buffer.</description><pubDate>Sun, 12 Jul 2026 12:00:00 GMT</pubDate><content:encoded>&lt;p&gt;Three CVEs in U-Boot’s network stack: one unchecked TCP header length that gives two reads past the packet, and an NFS path overflow past a 2048-byte buffer.&lt;/p&gt;&lt;p&gt;This post documents three vulnerabilities I discovered in U-Boot, the most widely deployed open-source bootloader in the embedded world. Two are in the TCP stack, both reached through a single header-length field that is never checked against the segment carrying it, and one is in the NFS client (a buffer overflow that lets a rogue NFS server redirect boot-image fetches and achieve code execution). All three were found using the same structured, multi-pass AI analysis workflow described in my earlier posts — applied this time to a codebase that runs before any operating system has loaded. The three CVEs are: CVE-2026-29007 — Out-of-bounds read in tcp_parse_options(), reached from tcp_rx_state_machine() when a packet declares a TCP header longer than the segment that carried it. CVE-2026-29008 — Integer underflow in tcp_rx_state_machine().&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://y637f9qq2x.com/posts/u-boot-tcp-nfs-vulns/&quot;&gt;Read the full post&lt;/a&gt; — 27 min read.&lt;/p&gt;</content:encoded><atom:updated>2026-09-13T00:00:00.000Z</atom:updated><dc:creator>Kazuma Matsumoto</dc:creator><media:thumbnail url="https://y637f9qq2x.com/og/u-boot-tcp-nfs-vulns.png" width="1200" height="630"/><category>cve</category><category>integer-underflow</category><category>buffer-overflow</category><category>u-boot</category><category>bootloader</category><category>vulnerability-research</category></item><item><title>Four Vulnerabilities in barebox: From DHCP Parsing to EFI PE Loading</title><link>https://y637f9qq2x.com/posts/barebox-sandbox-vulns/</link><guid isPermaLink="true">https://y637f9qq2x.com/posts/barebox-sandbox-vulns/</guid><description>Four CVEs in barebox: an unbounded DHCP option scan, two ext4 parsing flaws, and a PE virtual-size integer overflow in the EFI loader.</description><pubDate>Sun, 12 Jul 2026 10:00:00 GMT</pubDate><content:encoded>&lt;p&gt;Four CVEs in barebox: an unbounded DHCP option scan, two ext4 parsing flaws, and a PE virtual-size integer overflow in the EFI loader.&lt;/p&gt;&lt;p&gt;barebox is an open-source bootloader for embedded Linux systems — the first code that runs when an ARM, MIPS, RISC-V, or x86 device powers on. This post documents four vulnerabilities I discovered across three of its subsystems: The four bugs share a single root cause: barebox uses fields from on-disk and on-wire formats as loop bounds, pointer strides, and arithmetic operands without validating them. A DHCP option scanner with no check that the packet contains its own terminator. An ext4 loop bounded by an unvalidated entry count read straight from disk. A directory iterator that never checks for zero-length entries. A PE section-size computation that overflows because both of its operands are 32-bit header fields. Each fix is one or two lines of code; each was absent in released builds. Severity: none of these are remotely exploitable from the internet.&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://y637f9qq2x.com/posts/barebox-sandbox-vulns/&quot;&gt;Read the full post&lt;/a&gt; — 27 min read.&lt;/p&gt;</content:encoded><atom:updated>2026-09-13T00:00:00.000Z</atom:updated><dc:creator>Kazuma Matsumoto</dc:creator><media:thumbnail url="https://y637f9qq2x.com/og/barebox-sandbox-vulns.png" width="1200" height="630"/><category>cve</category><category>buffer-overflow</category><category>integer-overflow</category><category>barebox</category><category>bootloader</category><category>vulnerability-research</category></item><item><title>RogueProvision: A SYSTEM Task That Applies Unsigned Provisioning Packages — admin to SYSTEM, declined by MSRC</title><link>https://y637f9qq2x.com/posts/rogueprovision/</link><guid isPermaLink="true">https://y637f9qq2x.com/posts/rogueprovision/</guid><description>A SYSTEM service applies unsigned .ppkg packages from a folder — no signature, no consent. Microsoft’s docs promise otherwise. Honest catch: admin→SYSTEM.</description><pubDate>Mon, 22 Jun 2026 01:00:00 GMT</pubDate><content:encoded>&lt;p&gt;A SYSTEM service applies unsigned .ppkg packages from a folder — no signature, no consent. Microsoft’s docs promise otherwise. Honest catch: admin→SYSTEM.&lt;/p&gt;&lt;p&gt;A note on disclosure and MSRC’s view. This finding was reported to the Microsoft Security Response Center (MSRC). MSRC reviewed the submission and concluded that, because the demonstrated path is administrator→SYSTEM, it does not cross a serviceable security boundary under their Windows servicing model — so no fix is planned. I am publishing the technical analysis anyway, because the gap between the documented model and the implemented code path (Microsoft’s docs say admin and consent; the SYSTEM background path enforces neither) is interesting on its own terms — as a study in how documentation and implementation drift apart, and as a chain-sink for any other arbitrary-write primitive that lands a file in that folder. Everything below was reproduced on a lab machine I own. Proof-of-concept code is for reproduction and defense, not for use against anyone else.&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://y637f9qq2x.com/posts/rogueprovision/&quot;&gt;Read the full post&lt;/a&gt; — 48 min read.&lt;/p&gt;</content:encoded><atom:updated>2026-09-13T00:00:00.000Z</atom:updated><dc:creator>Kazuma Matsumoto</dc:creator><media:thumbnail url="https://y637f9qq2x.com/og/rogueprovision.png" width="1200" height="630"/><category>windows</category><category>vulnerability-research</category><category>lpe</category><category>privilege-escalation</category><category>provisioning</category><category>reverse-engineering</category><category>confused-deputy</category><category>not-vulns</category></item><item><title>Rebuilding a Security Researcher’s Mind in an AI — the Method, the Rig, and What It Cannot Do Yet</title><link>https://y637f9qq2x.com/posts/researchers-mind-in-ai/</link><guid isPermaLink="true">https://y637f9qq2x.com/posts/researchers-mind-in-ai/</guid><description>Building an AI that reverse-engineers undocumented Windows internals and raises its own hypotheses. The method, the rig, and the limit it has not crossed.</description><pubDate>Tue, 16 Jun 2026 01:00:00 GMT</pubDate><content:encoded>&lt;p&gt;Building an AI that reverse-engineers undocumented Windows internals and raises its own hypotheses. The method, the rig, and the limit it has not crossed.&lt;/p&gt;&lt;p&gt;An AI that finds a zero-day is no longer a shock — that capability is spreading fast, and finding more bugs of familiar kinds is not what this project is about. What far fewer people are building is an AI that invents: one that reaches for an attack technique nobody has described yet. That is what this project is for. The work is getting an AI to do Windows security research the way an experienced human researcher does. The goal is not to copy what the expert knows. That knowledge is facts like which Windows version or which function. Those can be looked up, and they change over time. The goal is to copy how the expert works: what they look at first, how they form a guess, and how hard they try to prove their own guess wrong before they believe it. And I should be clear up front about what kind of research, because it shapes every choice that follows.&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://y637f9qq2x.com/posts/researchers-mind-in-ai/&quot;&gt;Read the full post&lt;/a&gt; — 63 min read.&lt;/p&gt;</content:encoded><atom:updated>2026-09-13T00:00:00.000Z</atom:updated><dc:creator>Kazuma Matsumoto</dc:creator><media:thumbnail url="https://y637f9qq2x.com/og/researchers-mind-in-ai.png" width="1200" height="630"/><category>vulnerability-research</category><category>ai-agents</category><category>methodology</category><category>autonomous-research</category></item><item><title>Same Workflow, New Target: AI-Assisted Discovery of CVE-2026-29004 in BusyBox</title><link>https://y637f9qq2x.com/posts/cve-2026-29004/</link><guid isPermaLink="true">https://y637f9qq2x.com/posts/cve-2026-29004/</guid><description>How the AI workflow that found a strongSwan zero-day discovered a 9-year-old heap overflow in BusyBox’s DHCPv6 client, plus a full PoC walkthrough.</description><pubDate>Tue, 05 May 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;How the AI workflow that found a strongSwan zero-day discovered a 9-year-old heap overflow in BusyBox’s DHCPv6 client, plus a full PoC walkthrough.&lt;/p&gt;&lt;p&gt;This post documents CVE-2026-29004, a heap buffer overflow (a bug where a program writes more data into a dynamically allocated memory block than it can hold, spilling into adjacent memory) I discovered in BusyBox’s DHCPv6 client (udhcpc6). The bug had been present in the codebase for approximately 9 years — introduced in March 2017 and patched in March 2026. The vulnerability was found using the same structured, multi-pass AI analysis workflow that I described in detail in my previous post on CVE-2026-25075 (strongSwan). Rather than repeating the methodology here, this post focuses on the vulnerability itself — what it is and why it exists. For the full methodology, including the instruction document, session prompts, and false-positive elimination flow, see that earlier post. This is the second zero-day discovered using the same workflow.&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://y637f9qq2x.com/posts/cve-2026-29004/&quot;&gt;Read the full post&lt;/a&gt; — 35 min read.&lt;/p&gt;</content:encoded><atom:updated>2026-09-13T00:00:00.000Z</atom:updated><dc:creator>Kazuma Matsumoto</dc:creator><media:thumbnail url="https://y637f9qq2x.com/og/cve-2026-29004.png" width="1200" height="630"/><category>cve</category><category>heap-overflow</category><category>busybox</category><category>vulnerability-research</category></item><item><title>Finding a 15-Year-Old Zero-Day in strongSwan with AI-Assisted Code Analysis</title><link>https://y637f9qq2x.com/posts/cve-2026-25075/</link><guid isPermaLink="true">https://y637f9qq2x.com/posts/cve-2026-25075/</guid><description>How I discovered CVE-2026-25075, a bug hiding in strongSwan since 2010, using a structured multi-pass AI analysis workflow.</description><pubDate>Sat, 18 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;How I discovered CVE-2026-25075, a bug hiding in strongSwan since 2010, using a structured multi-pass AI analysis workflow.&lt;/p&gt;&lt;p&gt;This post documents CVE-2026-25075, a vulnerability I discovered in strongSwan, a widely used open-source IPsec VPN implementation. The bug had been present in the codebase for over 15 years before being patched in March 2026. Two things are covered here: What the vulnerability is — a technical walkthrough with explanations of the relevant concepts. This corresponds to Parts 1 and 2. How I found it — the structured, multi-pass AI analysis workflow I built (a “pass” here just means one round of analysis — the workflow uses several rounds in sequence), including the full specification document and session prompts I used. This corresponds to Parts 3 and 4. The methodology is the main focus. The vulnerability is the output; the process is what I think is worth sharing in detail.&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://y637f9qq2x.com/posts/cve-2026-25075/&quot;&gt;Read the full post&lt;/a&gt; — 28 min read.&lt;/p&gt;</content:encoded><atom:updated>2026-09-13T00:00:00.000Z</atom:updated><dc:creator>Kazuma Matsumoto</dc:creator><media:thumbnail url="https://y637f9qq2x.com/og/cve-2026-25075.png" width="1200" height="630"/><category>cve</category><category>integer-underflow</category><category>strongswan</category><category>vulnerability-research</category></item></channel></rss>