{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2025-7394", "assignerOrgId": "50d2cd11-d01a-48ed-9441-5bfce9d63b27", "state": "PUBLISHED", "assignerShortName": "wolfSSL", "dateReserved": "2025-07-09T16:38:33.567Z", "datePublished": "2025-07-18T22:34:23.849Z", "dateUpdated": "2025-07-21T15:00:21.780Z"}, "containers": {"cna": {"affected": [{"defaultStatus": "unaffected", "product": "wolfSSL", "repo": "https://github.com/wolfssl/wolfssl", "vendor": "wolfSSL", "versions": [{"lessThanOrEqual": "5.8.0", "status": "affected", "version": "3.15.0", "versionType": "git"}]}], "credits": [{"lang": "en", "type": "finder", "value": "Per Allansson"}], "descriptions": [{"lang": "en", "supportingMedia": [{"base64": false, "type": "text/html", "value": "<b><span style=\"background-color: transparent;\">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.</span></b><br>"}], "value": "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."}], "metrics": [{"cvssV4_0": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "attackVector": "NETWORK", "baseScore": 7, "baseSeverity": "HIGH", "privilegesRequired": "NONE", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "HIGH", "subIntegrityImpact": "NONE", "userInteraction": "PASSIVE", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "HIGH", "vulnIntegrityImpact": "NONE", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "format": "CVSS", "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "problemTypes": [{"descriptions": [{"cweId": "CWE-200", "description": "CWE-200 Exposure of Sensitive Information to an Unauthorized Actor", "lang": "en", "type": "CWE"}]}], "providerMetadata": {"orgId": "50d2cd11-d01a-48ed-9441-5bfce9d63b27", "shortName": "wolfSSL", "dateUpdated": "2025-07-18T22:57:53.350Z"}, "references": [{"url": "https://github.com/wolfSSL/wolfssl/blob/master/ChangeLog.md#wolfssl-release-582-july-17-2025"}], "source": {"discovery": "EXTERNAL"}, "x_generator": {"engine": "Vulnogram 0.2.0"}}, "adp": [{"metrics": [{"other": {"type": "ssvc", "content": {"timestamp": "2025-07-21T15:00:11.053980Z", "id": "CVE-2025-7394", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2025-07-21T15:00:21.780Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2025-7394", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2025-07-21T15:00:11.053980Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2025-07-21T15:00:14.044Z"}}], "cna": {"source": {"discovery": "EXTERNAL"}, "credits": [{"lang": "en", "type": "finder", "value": "Per Allansson"}], "metrics": [{"format": "CVSS", "cvssV4_0": {"Safety": "NOT_DEFINED", "version": "4.0", "Recovery": "NOT_DEFINED", "baseScore": 7, "Automatable": "NOT_DEFINED", "attackVector": "NETWORK", "baseSeverity": "HIGH", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N", "providerUrgency": "NOT_DEFINED", "userInteraction": "PASSIVE", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "privilegesRequired": "NONE", "subIntegrityImpact": "NONE", "vulnIntegrityImpact": "NONE", "subAvailabilityImpact": "NONE", "vulnAvailabilityImpact": "NONE", "subConfidentialityImpact": "HIGH", "vulnConfidentialityImpact": "HIGH", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "affected": [{"repo": "https://github.com/wolfssl/wolfssl", "vendor": "wolfSSL", "product": "wolfSSL", "versions": [{"status": "affected", "version": "3.15.0", "versionType": "git", "lessThanOrEqual": "5.8.0"}], "defaultStatus": "unaffected"}], "references": [{"url": "https://github.com/wolfSSL/wolfssl/blob/master/ChangeLog.md#wolfssl-release-582-july-17-2025"}], "x_generator": {"engine": "Vulnogram 0.2.0"}, "descriptions": [{"lang": "en", "value": "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.", "supportingMedia": [{"type": "text/html", "value": "<b><span style=\"background-color: transparent;\">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.</span></b><br>", "base64": false}]}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-200", "description": "CWE-200 Exposure of Sensitive Information to an Unauthorized Actor"}]}], "providerMetadata": {"orgId": "50d2cd11-d01a-48ed-9441-5bfce9d63b27", "shortName": "wolfSSL", "dateUpdated": "2025-07-18T22:57:53.350Z"}}}, "cveMetadata": {"cveId": "CVE-2025-7394", "state": "PUBLISHED", "dateUpdated": "2025-07-21T15:00:21.780Z", "dateReserved": "2025-07-09T16:38:33.567Z", "assignerOrgId": "50d2cd11-d01a-48ed-9441-5bfce9d63b27", "datePublished": "2025-07-18T22:34:23.849Z", "assignerShortName": "wolfSSL"}, "dataVersion": "5.1"}

{"cveTags": [], "descriptions": [{"lang": "en", "value": "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."}, {"lang": "es", "value": "En la implementaci\u00f3n de la capa de compatibilidad de OpenSSL, la funci\u00f3n RAND_poll() no se comportaba como se esperaba, lo que pod\u00eda generar valores predecibles de RAND_bytes() tras llamar a fork(). Esto puede generar n\u00fameros aleatorios d\u00e9biles o predecibles en aplicaciones que usan RAND_bytes() y realizan operaciones fork(). Esto solo afecta a las aplicaciones que llaman expl\u00edcitamente a RAND_bytes() despu\u00e9s de fork() y no afecta a las operaciones internas de TLS. Aunque la documentaci\u00f3n de RAND_bytes() en OpenSSL indica que no es seguro usarla con fork() sin llamar primero a RAND_poll(), tambi\u00e9n se realiz\u00f3 un cambio de c\u00f3digo adicional en wolfSSL para que RAND_bytes() se comporte de forma similar a OpenSSL tras una llamada a fork() sin llamar a RAND_poll(). Ahora, el Hash-DRBG utilizado se resembraliza tras detectar la ejecuci\u00f3n en un nuevo proceso. Si se utiliza RAND_bytes() y se llama a fork(), se recomienda actualizar a la \u00faltima versi\u00f3n de wolfSSL. Gracias a Per Allansson de Appgate por el informe."}], "id": "CVE-2025-7394", "lastModified": "2025-07-22T13:06:07.260", "metrics": {"cvssMetricV40": [{"cvssData": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "HIGH", "attackRequirements": "PRESENT", "attackVector": "NETWORK", "availabilityRequirement": "NOT_DEFINED", "baseScore": 7.0, "baseSeverity": "HIGH", "confidentialityRequirement": "NOT_DEFINED", "exploitMaturity": "NOT_DEFINED", "integrityRequirement": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "privilegesRequired": "NONE", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "HIGH", "subIntegrityImpact": "NONE", "userInteraction": "PASSIVE", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "HIGH", "vulnIntegrityImpact": "NONE", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "source": "facts@wolfssl.com", "type": "Secondary"}]}, "published": "2025-07-18T23:15:23.470", "references": [{"source": "facts@wolfssl.com", "url": "https://github.com/wolfSSL/wolfssl/blob/master/ChangeLog.md#wolfssl-release-582-july-17-2025"}], "sourceIdentifier": "facts@wolfssl.com", "vulnStatus": "Awaiting Analysis", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-200"}], "source": "facts@wolfssl.com", "type": "Secondary"}]}

{}

{"created": "2025-07-21T15:17:07.428856+00:00", "updated": "2025-07-21T15:17:07.428914+00:00", "vendors": ["wolfssl", "wolfssl$PRODUCT$wolfssl"]}