CVE-2026-45699 is an integer underflow in netatalk's copydir() function that allows heap corruption leading to remote code execution. The vulnerability lives in the error-handling path that executes when renameat() fails across device boundaries — a legitimate, routine operation that triggers silently when users move files across mount points within a shared volume. This is not a crafted-input bug; it's triggered by normal filesystem usage.
The underflow occurs in manual buffer tracking using srem and drem variables. When the code subtracts a value larger than the remaining buffer size, the result wraps to SIZE_MAX — a gigantic value that passes every boundary check. The function then writes beyond buffer limits, corrupting the heap in a network-facing daemon (afpd) that accepts connections in many default configurations.
What makes this particularly severe: the trigger is routine (cross-device moves), the failure is silent (no crash, just memory corruption), and the affected code sits in an error path that executes only under specific filesystem conditions. This is the sediment layer problem — error-handling code in rarely-executed paths accumulates technical debt without receiving maintenance attention. The developers who wrote this function are not the ones maintaining it today.
There's a documented workaround: avoid placing mount points within AFP-shared volumes. This isn't evidence the developers forgot about the code — it's evidence they knew it was fragile and chose documentation over remediation. That decision converted an acute vulnerability into chronic exposure, spreading the cost across every administrator who must architect around the bug rather than applying a patch.
Priority actions: verify you're running netatalk 4.4.3 or later; audit AFP shares for nested mount points that could trigger cross-device renames; review whether afpd is exposed to untrusted networks (this is a remote code execution vector in an unauthenticated daemon). Beyond patching, treat this as a signal to audit other rarely-executed error paths in your infrastructure — the entropy problem that created this vulnerability is almost certainly present elsewhere.