A WebDAV directory reply that crashed its reader: CVE-2026-43677

With a WebDAV share mounted on the test Mac, I could make its directory listing fail in two quite different ways. One left the Mac’s WebDAV service running. The other killed it. The visible result was an input/output error either way, which would have been a convenient place to stop investigating and a lousy place to draw a conclusion.

In my comparison, the non-crashing input left the service alive in six consecutive runs. The crashing input killed it in all three runs, with a fresh crash report each time. Both came from the same kind of server reply. The difference was buried in how Apple’s directory parser measured and copied text, and it mattered far more than the error printed by the file listing.

This research is associated with CVE-2026-43677, one of the five CVEs for which Apple credited Chris Bailey - Short Circuit in its September 14, 2026 releases. Apple describes an out-of-bounds write that could cause an application to terminate when connecting to a malicious WebDAV server. Its fix was to remove the vulnerable code.

Apple’s WebDAV entry in the macOS Golden Gate 27 security advisory

The server supplied the names. The Mac supplied the memory mistake.

WebDAV lets a server present remote files and folders over web protocols. On a Mac, a mounted WebDAV share can look enough like an ordinary directory that browsing it feels unremarkable. Underneath, the Mac still has to ask the server what is in that directory and turn the reply into entries it can display. The server supplies data; the Mac’s parser decides how that data fits in memory.

The affected code handled text within an XML directory-listing reply. XML is a structured text format, and its parser can deliver a piece of text along with its length. That length is part of the contract: it tells the receiving code how much of the supplied data belongs to this piece. The receiving code cannot safely assume that everything after it is more of the same string.

Apple’s code began with a size check. It limited the length of the text segment before copying it into a fixed-size destination. That would be reassuring if the code had continued using the number it had just checked. A later character-decoding operation instead scanned beyond the segment, calculated a different length and used that larger value for another copy. The server controlled the reply that supplied this second length.

The initial check and the later copy were therefore answering different questions. A short segment could pass validation while a subsequent scan reached much farther through the reply. Nothing brought that second measurement back within the destination’s capacity before the write. Data could spill out of the buffer and into memory beyond it: the heap overflow described in my report.

There was even another size check farther along, concerned with whether the completed name would fit. By then, the earlier copy had already happened. A warning about a name being too long is useful before writing it out of bounds; afterward it is mostly an explanation of the mess. The presence of several length checks did not make up for their disagreement about which length mattered.

I checked this against the compiled software, rather than relying only on Apple’s published source. The shipped memory layout differed from the public-source layout, and the actual allocation size matters when deciding where a write crosses a boundary. The affected routine had the same defective instruction sequence in the macOS 26.5.1 and 26.6 beta binaries I examined. That was static confirmation on the beta; the live crash and comparison evidence came from macOS 26.5.1 and 26.5.

A failed listing did not tell me enough

The live crash established that a server reply could bring down the shipping WebDAV agent on a stock Mac, from a standard user account. The diagnostic record led back through XML processing to the bad copy. It did not establish that the whole Mac crashed, that the server had gained extra privileges or that I could make the process execute instructions of my choosing. The observed failure belonged to the user’s WebDAV service.

My first check for crash reports looked in the system-wide directory. The agent’s reports were being written under the user account, and they did not appear immediately. I corrected the location, allowed for the delay and checked whether the process remained alive. The crashing input produced diagnostic reports through that same route. Against that comparison, the six surviving runs were meaningful; an empty directory alone would not have established survival.

The inputs that left the agent alive were just as important, but for a narrower reason. They took the non-crashing path associated with the overwrite in the code analysis. A process can survive a bad memory write if the damaged area is not immediately used in a way that faults. Its survival is not a clean bill of health. It also does not show exactly what neighboring live object was overwritten.

I used a separate in-process model to examine the write itself. It reproduced the relevant logic and the shipped allocation layout while using the real system XML parser. There, I could observe chosen data crossing the destination boundary and replacing a prepared marker in surrounding storage. A memory-error detector independently identified the out-of-bounds write. That made the relationship between the server-controlled reply and the overwritten bytes visible without pretending that the model was the live daemon.

The dividing line matters: I demonstrated a live crash, and the model demonstrated control over data written beyond the buffer. I did not demonstrate placing those bytes onto a selected neighboring object in the running service, turning that corruption into code execution, or extracting private memory. Those are additional results to prove, not benefits that arrive automatically with the phrase “heap overflow.”

The connection came first

The Mac had to connect to and mount the WebDAV share before the malicious reply could reach this parser. I demonstrated a mount without an authentication prompt, but I did not establish automatic mounting from an ordinary webpage, document or link. Those consumer paths were investigated; they did not supply a way around the connection prerequisite.

Once the share was mounted, directory requests from background indexing and Finder activity also reached the parser and produced crashes without another deliberate listing. Those requests depended on timing, while an explicit listing was repeatable. A mounted share therefore remained a source of server-controlled input during routine browsing and background work. In the running Mac, the consequence I demonstrated was the WebDAV agent failing while processing that input.

Apple removed the vulnerable code

Apple says it addressed this out-of-bounds write by removing the vulnerable code. I have not independently analyzed the patched binary. The advisory does not describe which surrounding operations changed; its wording should not be read as an announcement that WebDAV support was removed.

Apple lists CVE-2026-43677 in these September 14 releases. These links document where the fix first appeared in the published advisories; use the current supported update offered for your Mac.

This is a shared credit. Apple currently names Joseph Semaan, bubu, Omar Cerrito, HE WEI (ギカク), Roman Zabicki, Richard Zana, Chris Bailey - Short Circuit, Aswin Kumar Gokulakannan, Surya Narayan Kushwaha, Bruce Dang of Calif.io in collaboration with Claude and Anthropic Research. The entry was updated on October 19, 2026. My account here describes my own submitted research; the shared advisory does not establish that everyone listed found or tested the same path.

Thank you to Apple’s security and engineering teams for addressing the issue and acknowledging my research, and to the other researchers named in the shared credit.

Read the five September Apple credits and the other research articles

Apple’s advisories checked October 26, 2026.