Refine your search
4 vulnerabilities found for by ffmpeg
CVE-2025-59734 (GCVE-0-2025-59734)
Vulnerability from cvelistv5
Published
2025-10-06 08:09
Modified
2025-10-19 14:51
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-416 - Use After Free
Summary
It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion <2.
When a STOR chunk is present, a subsequent FOBJ chunk will be saved in ctx->stored_frame. Stored frames can later be referenced by FTCH chunks. For files using subversion < 2, the undecoded frame is stored, and decoded again when the FTCH chunks are parsed. However, in process_frame_obj if the frame has an invalid size, there’s an early return, with a value of 0.
This causes the code in decode_frame to still store the raw frame buffer into ctx->stored_frame. Leaving ctx->has_dimensions set to false.
A subsequent chunk with type FTCH would call process_ftch and decode that frame obj again, adding to the top/left values and calling process_frame_obj again.
Given that we never set ctx->have_dimensions before, this time we set the dimensions, calling init_buffers, which can reallocate the buffer in ctx->stored_frame, freeing the previous one. However, the GetByteContext object gb still holds a reference to the old buffer.
Finally, when the code tries to decode the frame, codecs that accept a GetByteContext as a parameter will trigger a use-after-free read when using gb.
GetByteContext is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the free and when the object is accessed. However, upon returning to process_ftch, the code restores the original values for top/left in stored_frame, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator’s metadata.
This issue can be triggered just by probing whether a file has the sanm format.
We recommend upgrading to version 8.0 or beyond.
References
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-59734",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-07T00:00:00+00:00",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-10-08T03:55:14.843Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://git.ffmpeg.org/ffmpeg.git",
"defaultStatus": "unaffected",
"packageName": "SANM",
"product": "FFmpeg",
"repo": "https://git.ffmpeg.org/ffmpeg.git",
"vendor": "FFmpeg",
"versions": [
{
"lessThan": "8.0",
"status": "affected",
"version": "4d7c609be37dc57d31527c8c9e5945dc9491a7cd",
"versionType": "custom"
},
{
"lessThan": "8.0",
"status": "affected",
"version": "7.1.1",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Google Big Sleep"
}
],
"datePublic": "2025-08-20T22:00:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003eIt is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion \u0026lt;2.\u003c/p\u003e\u003cp\u003eWhen a \u003ccode\u003eSTOR\u003c/code\u003e\u0026nbsp;chunk is present, a subsequent \u003ccode\u003eFOBJ\u003c/code\u003e\u0026nbsp;chunk will be saved in \u003ccode\u003ectx-\u0026gt;stored_frame\u003c/code\u003e. Stored frames can later be referenced by \u003ccode\u003eFTCH\u003c/code\u003e\u0026nbsp;chunks. For files using subversion \u0026lt; 2, the undecoded frame is stored, and decoded again when the \u003ccode\u003eFTCH\u003c/code\u003e\u0026nbsp;chunks are parsed.\u0026nbsp;\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eHowever, in \u003c/span\u003e\u003ccode\u003eprocess_frame_obj\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;if the frame has an invalid size, there\u2019s an early return, with a value of 0.\u0026nbsp;\u003c/span\u003e\u003c/p\u003e\u003cp\u003eThis causes the code in \u003ccode\u003edecode_frame\u003c/code\u003e\u0026nbsp;to still store the raw frame buffer into \u003ccode\u003ectx-\u0026gt;stored_frame\u003c/code\u003e. Leaving \u003ccode\u003ectx-\u0026gt;has_dimensions\u003c/code\u003e\u0026nbsp;set to \u003ccode\u003efalse\u003c/code\u003e.\u003c/p\u003e\u003cp\u003eA subsequent chunk with type \u003ccode\u003eFTCH\u003c/code\u003e\u0026nbsp;would call \u003ccode\u003eprocess_ftch\u003c/code\u003e\u0026nbsp;and decode that frame obj again, adding to the top/left values and calling \u003ccode\u003eprocess_frame_obj\u003c/code\u003e\u0026nbsp;again.\u003cbr\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eGiven that we never set \u003c/span\u003e\u003ccode\u003ectx-\u0026gt;have_dimensions\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;before, this time we set the dimensions, calling \u003c/span\u003e\u003ccode\u003einit_buffers\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e, which can reallocate the buffer in \u003c/span\u003e\u003ccode\u003ectx-\u0026gt;stored_frame\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e, freeing the previous one. However, the \u003c/span\u003e\u003ccode\u003eGetByteContext\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;object \u003c/span\u003e\u003ccode\u003egb\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;still holds a reference to the old buffer.\u003c/span\u003e\u003cbr\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003eFinally, when the code tries to decode the frame, codecs that accept a \u003ccode\u003eGetByteContext\u003c/code\u003e\u0026nbsp;as a parameter will trigger a use-after-free read when using \u003ccode\u003egb\u003c/code\u003e.\u003c/p\u003e\u003cp\u003e\u003ccode\u003eGetByteContext\u003c/code\u003e\u0026nbsp;is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the \u003ccode\u003efree\u003c/code\u003e\u0026nbsp;and when the object is accessed. However, upon returning to \u003ccode\u003eprocess_ftch\u003c/code\u003e, the code \u003cem\u003erestores\u003c/em\u003e\u0026nbsp;the original values for top/left in \u003ccode\u003estored_frame\u003c/code\u003e, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator\u2019s metadata.\u003c/p\u003e\u003cp\u003eThis issue can be triggered just by probing whether a file has the sanm format.\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003eWe recommend upgrading to version 8.0 or beyond.\u003cp\u003e\u003c/p\u003e\u003cbr\u003e"
}
],
"value": "It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion \u003c2.\n\nWhen a STOR\u00a0chunk is present, a subsequent FOBJ\u00a0chunk will be saved in ctx-\u003estored_frame. Stored frames can later be referenced by FTCH\u00a0chunks. For files using subversion \u003c 2, the undecoded frame is stored, and decoded again when the FTCH\u00a0chunks are parsed.\u00a0However, in process_frame_obj\u00a0if the frame has an invalid size, there\u2019s an early return, with a value of 0.\u00a0\n\nThis causes the code in decode_frame\u00a0to still store the raw frame buffer into ctx-\u003estored_frame. Leaving ctx-\u003ehas_dimensions\u00a0set to false.\n\nA subsequent chunk with type FTCH\u00a0would call process_ftch\u00a0and decode that frame obj again, adding to the top/left values and calling process_frame_obj\u00a0again.\nGiven that we never set ctx-\u003ehave_dimensions\u00a0before, this time we set the dimensions, calling init_buffers, which can reallocate the buffer in ctx-\u003estored_frame, freeing the previous one. However, the GetByteContext\u00a0object gb\u00a0still holds a reference to the old buffer.\n\n\n\n\nFinally, when the code tries to decode the frame, codecs that accept a GetByteContext\u00a0as a parameter will trigger a use-after-free read when using gb.\n\nGetByteContext\u00a0is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the free\u00a0and when the object is accessed. However, upon returning to process_ftch, the code restores\u00a0the original values for top/left in stored_frame, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator\u2019s metadata.\n\nThis issue can be triggered just by probing whether a file has the sanm format.\n\n\n\n\n\n\n\nWe recommend upgrading to version 8.0 or beyond."
}
],
"impacts": [
{
"capecId": "CAPEC-100",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-100 Overflow Buffers"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "NONE",
"attackVector": "ADJACENT",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-416",
"description": "CWE-416 Use After Free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-19T14:51:43.143Z",
"orgId": "14ed7db2-1595-443d-9d34-6215bf890778",
"shortName": "Google"
},
"references": [
{
"url": "https://issuetracker.google.com/440183164"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Heap-buffer-overflow write in FFmpeg SANM process_ftch",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "14ed7db2-1595-443d-9d34-6215bf890778",
"assignerShortName": "Google",
"cveId": "CVE-2025-59734",
"datePublished": "2025-10-06T08:09:44.280Z",
"dateReserved": "2025-09-19T08:11:37.550Z",
"dateUpdated": "2025-10-19T14:51:43.143Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2025-59733 (GCVE-0-2025-59733)
Vulnerability from cvelistv5
Published
2025-10-06 08:09
Modified
2025-10-19 14:52
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-787 - Out-of-bounds Write
Summary
When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are "B", "G", "R" and "A". The channel parsing code can be found in decode_header. The buffer td->uncompressed_data is allocated in decode_block based on the xsize, ysize and computed current_channel_offset.
The function dwa_uncompress then assumes at [5] that if there are 4 channels, these are "B", "G", "R" and "A", and in the calculations at [6] and [7] that all channels are of the same type, which matches the type of the main color channels.
If we set the main color channels to a 4-byte type and add duplicate or unknown channels of the 2-byte EXR_HALF type, then the addition at [7] will increment the pointer by 4-bytes * xsize * nb_channels, which will exceed the allocated buffer.
We recommend upgrading to version 8.0 or beyond.
References
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-59733",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-07T00:00:00+00:00",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-10-08T03:55:13.641Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://git.ffmpeg.org/ffmpeg.git",
"defaultStatus": "unaffected",
"packageName": "EXR",
"product": "FFmpeg",
"repo": "https://git.ffmpeg.org/ffmpeg.git",
"vendor": "FFmpeg",
"versions": [
{
"lessThan": "8.0",
"status": "affected",
"version": "9a32b863074ed4140141e0d3613905c6f1fe61c5",
"versionType": "custom"
},
{
"lessThan": "8.0",
"status": "affected",
"version": "7.1.1",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Google Big Sleep"
}
],
"datePublic": "2025-08-04T22:00:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eWhen decoding an OpenEXR file that uses DWAA or DWAB compression, there\u0027s an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are \u003c/span\u003e\u003ccode\u003e\"B\"\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e, \u003c/span\u003e\u003ccode\u003e\"G\"\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e, \u003c/span\u003e\u003ccode\u003e\"R\"\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;and \u003c/span\u003e\u003ccode\u003e\"A\"\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e. The channel parsing code can be found in \u003c/span\u003e\u003ccode\u003edecode_header.\u0026nbsp;\u003cp\u003eThe buffer \u003ccode\u003etd-\u0026gt;uncompressed_data\u003c/code\u003e\u0026nbsp;is allocated in \u003ccode\u003edecode_block\u003c/code\u003e\u0026nbsp;based on the \u003ccode\u003exsize\u003c/code\u003e, \u003ccode\u003eysize\u003c/code\u003e\u0026nbsp;and computed \u003ccode\u003ecurrent_channel_offset\u003c/code\u003e.\u003c/p\u003e\u003cp\u003eThe function \u003ccode\u003edwa_uncompress\u003c/code\u003e\u0026nbsp;then assumes at [5] that if there are 4 channels, these are \u003ccode\u003e\"B\"\u003c/code\u003e, \u003ccode\u003e\"G\"\u003c/code\u003e, \u003ccode\u003e\"R\"\u003c/code\u003e\u0026nbsp;and \u003ccode\u003e\"A\"\u003c/code\u003e, and in the calculations at [6] and [7] that all channels are of the same type, which matches the type of the main color channels.\u003c/p\u003e\u003cp\u003eIf we set the main color channels to a 4-byte type and add duplicate or unknown channels of the 2-byte \u003ccode\u003eEXR_HALF\u003c/code\u003e\u0026nbsp;type, then the addition at [7] will increment the pointer by \u003ccode\u003e4-bytes * xsize * nb_channels\u003c/code\u003e, which will exceed the allocated buffer.\u003c/p\u003e\u003c/code\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003eWe recommend upgrading to version 8.0 or beyond.\u003cp\u003e\u003c/p\u003e\u003cbr\u003e"
}
],
"value": "When decoding an OpenEXR file that uses DWAA or DWAB compression, there\u0027s an implicit assumption that all image channels have the same pixel type (and size), and that if there are four channels, the first four are \"B\", \"G\", \"R\"\u00a0and \"A\". The channel parsing code can be found in decode_header.\u00a0The buffer td-\u003euncompressed_data\u00a0is allocated in decode_block\u00a0based on the xsize, ysize\u00a0and computed current_channel_offset.\n\nThe function dwa_uncompress\u00a0then assumes at [5] that if there are 4 channels, these are \"B\", \"G\", \"R\"\u00a0and \"A\", and in the calculations at [6] and [7] that all channels are of the same type, which matches the type of the main color channels.\n\nIf we set the main color channels to a 4-byte type and add duplicate or unknown channels of the 2-byte EXR_HALF\u00a0type, then the addition at [7] will increment the pointer by 4-bytes * xsize * nb_channels, which will exceed the allocated buffer.\n\n\n\n\n\nWe recommend upgrading to version 8.0 or beyond."
}
],
"impacts": [
{
"capecId": "CAPEC-100",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-100 Overflow Buffers"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "NONE",
"attackVector": "ADJACENT",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-787",
"description": "CWE-787 Out-of-bounds Write",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-19T14:52:14.577Z",
"orgId": "14ed7db2-1595-443d-9d34-6215bf890778",
"shortName": "Google"
},
"references": [
{
"url": "https://issuetracker.google.com/436511754"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "14ed7db2-1595-443d-9d34-6215bf890778",
"assignerShortName": "Google",
"cveId": "CVE-2025-59733",
"datePublished": "2025-10-06T08:09:37.290Z",
"dateReserved": "2025-09-19T08:11:37.550Z",
"dateUpdated": "2025-10-19T14:52:14.577Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2025-59732 (GCVE-0-2025-59732)
Vulnerability from cvelistv5
Published
2025-10-06 08:09
Modified
2025-10-19 14:52
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-787 - Out-of-bounds Write
Summary
When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that the height and width are divisible by 8.
If the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8.
The buffer td->uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the "rounded-up" multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory.
We recommend upgrading to version 8.0 or beyond.
References
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-59732",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-07T00:00:00+00:00",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-10-08T03:55:12.275Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://git.ffmpeg.org/ffmpeg.git",
"defaultStatus": "unaffected",
"packageName": "EXR",
"product": "FFmpeg",
"repo": "https://git.ffmpeg.org/ffmpeg.git",
"vendor": "FFmpeg",
"versions": [
{
"lessThan": "8.0",
"status": "affected",
"version": "9a32b863074ed4140141e0d3613905c6f1fe61c5",
"versionType": "custom"
},
{
"lessThan": "8.0",
"status": "affected",
"version": "7.1.1",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Google Big Sleep"
}
],
"datePublic": "2025-08-04T22:00:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003eWhen decoding an OpenEXR file that uses DWAA or DWAB compression, there\u0027s an implicit assumption that the height and width are divisible by 8.\u003c/p\u003e\u003cp\u003eIf the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8.\u003c/p\u003e\u003cp\u003eThe buffer \u003ccode\u003etd-\u0026gt;uncompressed_data\u003c/code\u003e\u0026nbsp;is allocated in \u003ccode\u003edecode_block\u003c/code\u003e\u0026nbsp;based on the precise height and width of the image, so the \"rounded-up\" multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory.\u003c/p\u003e\u003cp\u003e\u003c/p\u003eWe recommend upgrading to version 8.0 or beyond.\u003cp\u003e\u003c/p\u003e\u003cbr\u003e"
}
],
"value": "When decoding an OpenEXR file that uses DWAA or DWAB compression, there\u0027s an implicit assumption that the height and width are divisible by 8.\n\nIf the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8.\n\nThe buffer td-\u003euncompressed_data\u00a0is allocated in decode_block\u00a0based on the precise height and width of the image, so the \"rounded-up\" multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory.\n\n\n\nWe recommend upgrading to version 8.0 or beyond."
}
],
"impacts": [
{
"capecId": "CAPEC-100",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-100 Overflow Buffers"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "NONE",
"attackVector": "ADJACENT",
"baseScore": 8.7,
"baseSeverity": "HIGH",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-787",
"description": "CWE-787 Out-of-bounds Write",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-19T14:52:36.920Z",
"orgId": "14ed7db2-1595-443d-9d34-6215bf890778",
"shortName": "Google"
},
"references": [
{
"url": "https://issuetracker.google.com/436510316"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "14ed7db2-1595-443d-9d34-6215bf890778",
"assignerShortName": "Google",
"cveId": "CVE-2025-59732",
"datePublished": "2025-10-06T08:09:31.276Z",
"dateReserved": "2025-09-19T08:11:37.550Z",
"dateUpdated": "2025-10-19T14:52:36.920Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2025-59731 (GCVE-0-2025-59731)
Vulnerability from cvelistv5
Published
2025-10-06 08:09
Modified
2025-10-19 14:53
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-787 - Out-of-bounds Write
Summary
When decoding an OpenEXR file that uses DWAA or DWAB compression, the specified raw length of run-length-encoded data is not checked when using it to calculate the output data.
We read rle_raw_size from the input file at [0], we decompress and decode into the buffer td->rle_raw_data of size rle_raw_size at [1], and then at [2] we will access entries in this buffer up to (td->xsize - 1) * (td->ysize - 1) + rle_raw_size / 2, which may exceed rle_raw_size.
We recommend upgrading to version 8.0 or beyond.
References
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-59731",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-07T00:00:00+00:00",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-10-08T03:55:11.056Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://git.ffmpeg.org/ffmpeg.git",
"defaultStatus": "unaffected",
"packageName": "EXR",
"product": "FFmpeg",
"repo": "https://git.ffmpeg.org/ffmpeg.git",
"vendor": "FFmpeg",
"versions": [
{
"lessThan": "8.0",
"status": "affected",
"version": "9a32b863074ed4140141e0d3613905c6f1fe61c5",
"versionType": "custom"
},
{
"lessThan": "8.0",
"status": "affected",
"version": "7.1.1",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Google Big Sleep"
}
],
"datePublic": "2025-08-04T22:00:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003eWhen decoding an OpenEXR file that uses DWAA or DWAB compression, the specified raw length of run-length-encoded data is not checked when using it to calculate the output data.\u003c/p\u003e\u003cp\u003eWe read \u003ccode\u003erle_raw_size\u003c/code\u003e\u0026nbsp;from the input file at [0], we decompress and decode into the buffer \u003ccode\u003etd-\u0026gt;rle_raw_data\u003c/code\u003e\u0026nbsp;of size \u003ccode\u003erle_raw_size\u003c/code\u003e\u0026nbsp;at [1], and then at [2] we will access entries in this buffer up to \u003ccode\u003e(td-\u0026gt;xsize - 1) * (td-\u0026gt;ysize - 1) + rle_raw_size / 2\u003c/code\u003e, which may exceed \u003ccode\u003erle_raw_size\u003c/code\u003e.\u003cbr\u003e\u003c/p\u003e\u003cp\u003e\u003c/p\u003eWe recommend upgrading to version 8.0 or beyond.\u003cp\u003e\u003c/p\u003e\u003cbr\u003e"
}
],
"value": "When decoding an OpenEXR file that uses DWAA or DWAB compression, the specified raw length of run-length-encoded data is not checked when using it to calculate the output data.\n\nWe read rle_raw_size\u00a0from the input file at [0], we decompress and decode into the buffer td-\u003erle_raw_data\u00a0of size rle_raw_size\u00a0at [1], and then at [2] we will access entries in this buffer up to (td-\u003exsize - 1) * (td-\u003eysize - 1) + rle_raw_size / 2, which may exceed rle_raw_size.\n\n\n\n\nWe recommend upgrading to version 8.0 or beyond."
}
],
"impacts": [
{
"capecId": "CAPEC-100",
"descriptions": [
{
"lang": "en",
"value": "CAPEC-100 Overflow Buffers"
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "NONE",
"attackVector": "ADJACENT",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:A/AC:H/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-787",
"description": "CWE-787 Out-of-bounds Write",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-19T14:53:00.719Z",
"orgId": "14ed7db2-1595-443d-9d34-6215bf890778",
"shortName": "Google"
},
"references": [
{
"url": "https://issuetracker.google.com/436510153"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Heap-buffer-overflow write in FFmpeg EXR dwa_uncompress",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "14ed7db2-1595-443d-9d34-6215bf890778",
"assignerShortName": "Google",
"cveId": "CVE-2025-59731",
"datePublished": "2025-10-06T08:09:23.410Z",
"dateReserved": "2025-09-19T08:11:37.550Z",
"dateUpdated": "2025-10-19T14:53:00.719Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}