The vulnerability in CVE-2026-45100 is straightforward: a size check validates that base64 input fits in a 64KB buffer but ignores the ~33% expansion that occurs during encoding. The overflow writes up to 21,844 bytes of attacker-controlled data into heap memory. That's the textbook part. What makes this severe is what happens next.
OpenSIPS reuses transformation buffers across chained operations. The same buffer that receives your overflow is read by the subsequent transformation in the pipeline—and that subsequent operation treats the corrupted content as trusted. You're not corrupting memory with garbage that crashes the program; you're corrupting it with structured, valid base64 that the next transformation will successfully decode and process. This converts a bounded overflow into unbounded influence over program behavior.
This is not a universal exploitation scenario. The vulnerability only triggers when your OpenSIPS routing configuration applies base64 encoding to user-controlled SIP headers—typically through a pattern like s.b64encode on external input. If your deployment doesn't use this pattern, you're running a vulnerable binary but the attack surface doesn't exist. Audit your routing scripts for any transformation that encodes user-supplied data; that's where your exposure lives.
The patch fixes the immediate size-check bug. The architectural lesson is larger: buffer reuse across transformations creates security-critical shared state, and when that buffer contains attacker-controlled data, the overflow becomes a trust-corruption vulnerability rather than a crash condition. When you design transformation pipelines, treat shared buffers as requiring the same rigor as authentication logic—document the invariants, because a developer's size-check error should not be able to inject attacker-controlled data into a context the program will subsequently trust.