---
When browsing security updates or scanning for new vulnerabilities, you may have come across CVE-2023-5129. However, you might also see a confusing message: _"This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. Duplicate of CVE-2023-4863."_ In this article, we’ll break down what that means, the story behind it, and how it relates to real-world security risks.
What is CVE-2023-5129?
First, a CVE (Common Vulnerabilities and Exposures) ID is just a unique number given to a security flaw. It helps people talk about and fix vulnerabilities quickly. Sometimes, two different reporters assign new numbers to the same bug, creating duplicates. That’s what happened here.
CVE-2023-5129 was created, but later rejected because it describes the _same_ issue as CVE-2023-4863. If you want to learn more about the actual security bug, you need to look up CVE-2023-4863.
Here’s the text from the official CVE site
> REJECT
>
> This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
> Duplicate of CVE-2023-4863.
Background
CVE-2023-4863 is a critical heap buffer overflow found in the libwebp image library. This library is used by tons of browsers (Chrome, Edge, Firefox), apps, and other software to load WebP images. A specially crafted WebP image could let attackers run arbitrary code on your machine.
References
- NIST CVE-2023-4863
- libwebp advisory
- Google Chrome release notes
How the Exploit Works
The vulnerability lives in the way libwebp handled "lossless" WebP images. By making the decoder process a specially-crafted (“malicious”) image, attackers could write past the end of a heap buffer (overflow it) — potentially letting them crash your app, run malware, or take over machines.
Here’s a simplified example of how a vulnerable snippet might look
// Vulnerable code in libwebp decoder (simplified!)
size_t size = ...; // comes from untrusted WebP header
uint8_t* buf = malloc(size);
// ... processing with unchecked size ...
memcpy(buf, src, size); // could overflow if 'size' is wrong!
A valid, but evil, WebP file could make size much too big, allowing memcpy to overwrite memory.
Proof of Concept
Exploit in the Wild?
Security researchers quickly published example files after the bug became public. Here’s a small code snippet showing how you might test:
# Sample to create a fuzzed WebP file
from PIL import Image
im = Image.new("RGBA", (10, 10), (255, , , ))
im.save("test.webp", "WEBP")
# Now, use a fuzzing tool to mutate test.webp and look for crashes in libwebp-enabled software
Some exploit writers built images that—even in browsers—could run their own code!
libwebp was patched in version 1.3.2.
Browser vendors like Chrome, Edge, and Firefox updated their code quickly.
- Action: If you manage servers, apps, or desktops using libwebp or any image processing tools, update NOW.
CVE-2023-5129 is a rejected duplicate. Ignore it; focus on CVE-2023-4863 for the real issue.
- This vulnerability allowed bad actors to take control of systems just by getting victims to open, view, or handle their WebP image.
- If you handle images (even if you’re not a web browser), your software might be at risk—update libraries and stay alert.
References & Further Reading
- CVE-2023-4863 at NIST
- libwebp Issue #694: Security vulnerability
- Chrome Security Update
- Pillow (PIL Fork) Security Note
Wrap Up:
Don’t be confused by extra CVE numbers. CVE-2023-4863 is the one that matters—a real threat, now mostly fixed. Check your software and update to keep yourself and your users secure!
Timeline
Published on: 09/25/2023 21:15:16 UTC
Last modified on: 11/07/2023 04:23:29 UTC