msrc_cve-2025-7394
Vulnerability from csaf_microsoft
Published
2025-07-02 00:00
Modified
2025-09-04 03:46
Summary
In the OpenSSL compatibility layer implementation, the function RAND_poll() was not behaving as expected and leading to the potential for predictable values returned from RAND_bytes() after fork() is called. This can lead to weak or predictable random numbers generated in applications that are both using RAND_bytes() and doing fork() operations. This only affects applications explicitly calling RAND_bytes() after fork() and does not affect any internal TLS operations. Although RAND_bytes() documentation in OpenSSL calls out not being safe for use with fork() without first calling RAND_poll(), an additional code change was also made in wolfSSL to make RAND_bytes() behave similar to OpenSSL after a fork() call without calling RAND_poll(). Now the Hash-DRBG used gets reseeded after detecting running in a new process. If making use of RAND_bytes() and calling fork() we recommend updating to the latest version of wolfSSL. Thanks to Per Allansson from Appgate for the report.
Notes
Additional Resources
To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle
Disclaimer
The information provided in the Microsoft Knowledge Base is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
{
"document": {
"category": "csaf_vex",
"csaf_version": "2.0",
"distribution": {
"text": "Public",
"tlp": {
"label": "WHITE",
"url": "https://www.first.org/tlp/"
}
},
"lang": "en-US",
"notes": [
{
"category": "general",
"text": "To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle",
"title": "Additional Resources"
},
{
"category": "legal_disclaimer",
"text": "The information provided in the Microsoft Knowledge Base is provided \\\"as is\\\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.",
"title": "Disclaimer"
}
],
"publisher": {
"category": "vendor",
"contact_details": "secure@microsoft.com",
"name": "Microsoft Security Response Center",
"namespace": "https://msrc.microsoft.com"
},
"references": [
{
"category": "self",
"summary": "CVE-2025-7394 In the OpenSSL compatibility layer implementation, the function RAND_poll() was not behaving as expected and leading to the potential for predictable values returned from RAND_bytes() after fork() is called. This can lead to weak or predictable random numbers generated in applications that are both using RAND_bytes() and doing fork() operations. This only affects applications explicitly calling RAND_bytes() after fork() and does not affect any internal TLS operations. Although RAND_bytes() documentation in OpenSSL calls out not being safe for use with fork() without first calling RAND_poll(), an additional code change was also made in wolfSSL to make RAND_bytes() behave similar to OpenSSL after a fork() call without calling RAND_poll(). Now the Hash-DRBG used gets reseeded after detecting running in a new process. If making use of RAND_bytes() and calling fork() we recommend updating to the latest version of wolfSSL. Thanks to Per Allansson from Appgate for the report. - VEX",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-7394.json"
},
{
"category": "external",
"summary": "Microsoft Support Lifecycle",
"url": "https://support.microsoft.com/lifecycle"
},
{
"category": "external",
"summary": "Common Vulnerability Scoring System",
"url": "https://www.first.org/cvss"
}
],
"title": "In the OpenSSL compatibility layer implementation, the function RAND_poll() was not behaving as expected and leading to the potential for predictable values returned from RAND_bytes() after fork() is called. This can lead to weak or predictable random numbers generated in applications that are both using RAND_bytes() and doing fork() operations. This only affects applications explicitly calling RAND_bytes() after fork() and does not affect any internal TLS operations. Although RAND_bytes() documentation in OpenSSL calls out not being safe for use with fork() without first calling RAND_poll(), an additional code change was also made in wolfSSL to make RAND_bytes() behave similar to OpenSSL after a fork() call without calling RAND_poll(). Now the Hash-DRBG used gets reseeded after detecting running in a new process. If making use of RAND_bytes() and calling fork() we recommend updating to the latest version of wolfSSL. Thanks to Per Allansson from Appgate for the report.",
"tracking": {
"current_release_date": "2025-09-04T03:46:05.000Z",
"generator": {
"date": "2025-10-20T03:36:12.162Z",
"engine": {
"name": "MSRC Generator",
"version": "1.0"
}
},
"id": "msrc_CVE-2025-7394",
"initial_release_date": "2025-07-02T00:00:00.000Z",
"revision_history": [
{
"date": "2025-09-04T03:46:05.000Z",
"legacy_version": "1",
"number": "1",
"summary": "Information published."
}
],
"status": "final",
"version": "1"
}
},
"product_tree": {
"branches": [
{
"branches": [
{
"branches": [
{
"category": "product_version",
"name": "2.0",
"product": {
"name": "CBL Mariner 2.0",
"product_id": "17086"
}
},
{
"category": "product_version",
"name": "3.0",
"product": {
"name": "Azure Linux 3.0",
"product_id": "17084"
}
}
],
"category": "product_name",
"name": "Azure Linux"
},
{
"branches": [
{
"category": "product_version_range",
"name": "\u003ccbl2 mariadb 10.6.21-1",
"product": {
"name": "\u003ccbl2 mariadb 10.6.21-1",
"product_id": "1"
}
},
{
"category": "product_version",
"name": "cbl2 mariadb 10.6.21-1",
"product": {
"name": "cbl2 mariadb 10.6.21-1",
"product_id": "20085"
}
},
{
"category": "product_version_range",
"name": "\u003cazl3 mariadb 10.11.11-1",
"product": {
"name": "\u003cazl3 mariadb 10.11.11-1",
"product_id": "2"
}
},
{
"category": "product_version",
"name": "azl3 mariadb 10.11.11-1",
"product": {
"name": "azl3 mariadb 10.11.11-1",
"product_id": "19283"
}
}
],
"category": "product_name",
"name": "mariadb"
}
],
"category": "vendor",
"name": "Microsoft"
}
],
"relationships": [
{
"category": "default_component_of",
"full_product_name": {
"name": "\u003ccbl2 mariadb 10.6.21-1 as a component of CBL Mariner 2.0",
"product_id": "17086-1"
},
"product_reference": "1",
"relates_to_product_reference": "17086"
},
{
"category": "default_component_of",
"full_product_name": {
"name": "cbl2 mariadb 10.6.21-1 as a component of CBL Mariner 2.0",
"product_id": "20085-17086"
},
"product_reference": "20085",
"relates_to_product_reference": "17086"
},
{
"category": "default_component_of",
"full_product_name": {
"name": "\u003cazl3 mariadb 10.11.11-1 as a component of Azure Linux 3.0",
"product_id": "17084-2"
},
"product_reference": "2",
"relates_to_product_reference": "17084"
},
{
"category": "default_component_of",
"full_product_name": {
"name": "azl3 mariadb 10.11.11-1 as a component of Azure Linux 3.0",
"product_id": "19283-17084"
},
"product_reference": "19283",
"relates_to_product_reference": "17084"
}
]
},
"vulnerabilities": [
{
"cve": "CVE-2025-7394",
"cwe": {
"id": "CWE-200",
"name": "Exposure of Sensitive Information to an Unauthorized Actor"
},
"notes": [
{
"category": "general",
"text": "wolfSSL",
"title": "Assigning CNA"
}
],
"product_status": {
"fixed": [
"20085-17086",
"19283-17084"
],
"known_affected": [
"17086-1",
"17084-2"
]
},
"references": [
{
"category": "self",
"summary": "CVE-2025-7394 In the OpenSSL compatibility layer implementation, the function RAND_poll() was not behaving as expected and leading to the potential for predictable values returned from RAND_bytes() after fork() is called. This can lead to weak or predictable random numbers generated in applications that are both using RAND_bytes() and doing fork() operations. This only affects applications explicitly calling RAND_bytes() after fork() and does not affect any internal TLS operations. Although RAND_bytes() documentation in OpenSSL calls out not being safe for use with fork() without first calling RAND_poll(), an additional code change was also made in wolfSSL to make RAND_bytes() behave similar to OpenSSL after a fork() call without calling RAND_poll(). Now the Hash-DRBG used gets reseeded after detecting running in a new process. If making use of RAND_bytes() and calling fork() we recommend updating to the latest version of wolfSSL. Thanks to Per Allansson from Appgate for the report. - VEX",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-7394.json"
}
],
"remediations": [
{
"category": "vendor_fix",
"date": "2025-09-04T03:46:05.000Z",
"details": "Security Update:https://learn.microsoft.com/en-us/azure/azure-linux/tutorial-azure-linux-upgrade",
"product_ids": [
"17086-1",
"17084-2"
],
"url": "https://learn.microsoft.com/en-us/azure/azure-linux/tutorial-azure-linux-upgrade"
}
],
"title": "In the OpenSSL compatibility layer implementation, the function RAND_poll() was not behaving as expected and leading to the potential for predictable values returned from RAND_bytes() after fork() is called. This can lead to weak or predictable random numbers generated in applications that are both using RAND_bytes() and doing fork() operations. This only affects applications explicitly calling RAND_bytes() after fork() and does not affect any internal TLS operations. Although RAND_bytes() documentation in OpenSSL calls out not being safe for use with fork() without first calling RAND_poll(), an additional code change was also made in wolfSSL to make RAND_bytes() behave similar to OpenSSL after a fork() call without calling RAND_poll(). Now the Hash-DRBG used gets reseeded after detecting running in a new process. If making use of RAND_bytes() and calling fork() we recommend updating to the latest version of wolfSSL. Thanks to Per Allansson from Appgate for the report."
}
]
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…