mirror of
https://github.com/netbirdio/advisory-database.git
synced 2026-05-22 18:04:22 -07:00
Publish Advisories
GHSA-gw5p-q8mj-p7gh GHSA-7qmx-3fpx-r45m GHSA-q8hx-mm92-4wvg GHSA-c2f5-jxjv-2hh8 GHSA-8x27-jwjr-8545
This commit is contained in:
advisory-database[bot]
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-gw5p-q8mj-p7gh",
|
||||
"modified": "2023-09-14T19:33:17Z",
|
||||
"modified": "2025-05-02T12:53:12Z",
|
||||
"published": "2023-09-14T19:33:17Z",
|
||||
"aliases": [
|
||||
"CVE-2023-41880"
|
||||
],
|
||||
"summary": "Miscompilation of wasm `i64x2.shr_s` instruction with constant input on x86_64",
|
||||
"details": "### Impact\n\nWasmtime versions from 10.0.0 to 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result.\n\nThis issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.\n\nThis issue was discovered through fuzzing of Wasmtime's code generator Cranelift.\n\n### Patches\n\nWasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation.\n\n### Workarounds\n\nThis issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to [disable the SIMD proposal for WebAssembly](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd). Users prior to 10.0.0 are unaffected by this vulnerability.\n\n### References\n\n* [PR which introduced this bug to Wasmtime](https://github.com/bytecodealliance/wasmtime/pull/6372)\n* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/B8PJgg6bEdg)\n",
|
||||
"details": "### Impact\n\nWasmtime versions from 10.0.0 to 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result.\n\nThis issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless.\n\nThis issue was discovered through fuzzing of Wasmtime's code generator Cranelift.\n\n### Patches\n\nWasmtime versions 10.0.2, 11.0.2, and 12.0.2 are all patched to no longer have this miscompilation.\n\n### Workarounds\n\nThis issue only affects x86_64 hosts and the only workaround is to either scan for this pattern in wasm modules which is nontrivial or to [disable the SIMD proposal for WebAssembly](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd). Users prior to 10.0.0 are unaffected by this vulnerability.\n\n### References\n\n* [PR which introduced this bug to Wasmtime](https://github.com/bytecodealliance/wasmtime/pull/6372)\n* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/B8PJgg6bEdg)",
|
||||
"severity": [
|
||||
{
|
||||
"type": "CVSS_V3",
|
||||
@@ -101,6 +101,10 @@
|
||||
{
|
||||
"type": "PACKAGE",
|
||||
"url": "https://github.com/bytecodealliance/wasmtime"
|
||||
},
|
||||
{
|
||||
"type": "WEB",
|
||||
"url": "https://rustsec.org/advisories/RUSTSEC-2023-0091.html"
|
||||
}
|
||||
],
|
||||
"database_specific": {
|
||||
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-c2f5-jxjv-2hh8",
|
||||
"modified": "2024-11-06T14:28:16Z",
|
||||
"modified": "2025-05-02T12:53:57Z",
|
||||
"published": "2024-11-05T22:18:49Z",
|
||||
"aliases": [
|
||||
"CVE-2024-51745"
|
||||
],
|
||||
"summary": "Wasmtime doesn't fully sandbox all the Windows device filenames",
|
||||
"details": "### Impact\n\nWasmtime's filesystem sandbox implementation on Windows blocks access to special device filenames such as \"COM1\", \"COM2\", \"LPT0\", \"LPT1\", and so on, however it did not block access to the special device filenames which use superscript digits, such as \"COM¹\", \"COM²\", \"LPT⁰\", \"LPT¹\", and so on. Untrusted Wasm programs that are given access to any filesystem directory could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them gain access peripheral devices connected to the computer, or network resources mapped to those devices. This can include modems, printers, network printers, and any other device connected to a serial or parallel port, including emulated USB serial ports.\n\n### Patches\n\nPatch releases for Wasmtime have been issued as 24.0.2, 25.0.3, and 26.0.1. Users of Wasmtime 23.0.x and prior are recommended to upgrade to one of these patched versions.\n\n### Workarounds\n\nThere are no known workarounds for this issue. Affected Windows users are recommended to upgrade.\n\n### References\n\n - [Microsoft's documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions) of the special device filenames\n - [ISO-8859-1](https://en.wikipedia.org/wiki/ISO/IEC_8859-1)\n - [The original PR reporting the issue](https://github.com/bytecodealliance/cap-std/pull/371)\n",
|
||||
"details": "### Impact\n\nWasmtime's filesystem sandbox implementation on Windows blocks access to special device filenames such as \"COM1\", \"COM2\", \"LPT0\", \"LPT1\", and so on, however it did not block access to the special device filenames which use superscript digits, such as \"COM¹\", \"COM²\", \"LPT⁰\", \"LPT¹\", and so on. Untrusted Wasm programs that are given access to any filesystem directory could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them gain access peripheral devices connected to the computer, or network resources mapped to those devices. This can include modems, printers, network printers, and any other device connected to a serial or parallel port, including emulated USB serial ports.\n\n### Patches\n\nPatch releases for Wasmtime have been issued as 24.0.2, 25.0.3, and 26.0.1. Users of Wasmtime 23.0.x and prior are recommended to upgrade to one of these patched versions.\n\n### Workarounds\n\nThere are no known workarounds for this issue. Affected Windows users are recommended to upgrade.\n\n### References\n\n - [Microsoft's documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions) of the special device filenames\n - [ISO-8859-1](https://en.wikipedia.org/wiki/ISO/IEC_8859-1)\n - [The original PR reporting the issue](https://github.com/bytecodealliance/cap-std/pull/371)",
|
||||
"severity": [
|
||||
{
|
||||
"type": "CVSS_V4",
|
||||
@@ -100,6 +100,10 @@
|
||||
{
|
||||
"type": "WEB",
|
||||
"url": "https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions"
|
||||
},
|
||||
{
|
||||
"type": "WEB",
|
||||
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0438.html"
|
||||
}
|
||||
],
|
||||
"database_specific": {
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"schema_version": "1.4.0",
|
||||
"id": "GHSA-8x27-jwjr-8545",
|
||||
"modified": "2025-05-01T13:59:51Z",
|
||||
"modified": "2025-05-02T12:53:39Z",
|
||||
"published": "2025-05-01T13:59:51Z",
|
||||
"aliases": [
|
||||
"CVE-2025-46337"
|
||||
],
|
||||
"summary": "SQL injection in ADOdb PostgreSQL driver pg_insert_id() method",
|
||||
"details": "Improper escaping of a query parameter may allow an attacker to execute arbitrary SQL statements when the code using ADOdb connects to a PostgreSQL database and calls pg_insert_id() with user-supplied data.\n\nNote that the indicated Severity corresponds to a worst-case usage scenario.\n\n### Impact\nPostgreSQL drivers (postgres64, postgres7, postgres8, postgres9).\n\n### Patches\nVulnerability is fixed in ADOdb 5.22.9 (11107d6d6e5160b62e05dff8a3a2678cf0e3a426).\n\n### Workarounds\nOnly pass controlled data to pg_insert_id() method's $fieldname parameter, or escape it with pg_escape_identifier() first.\n\n### Credits\nThanks to Marco Nappi (@mrcnpp) for reporting this vulnerability.",
|
||||
"details": "Improper escaping of a query parameter may allow an attacker to execute arbitrary SQL statements when the code using ADOdb connects to a PostgreSQL database and calls pg_insert_id() with user-supplied data.\n\nNote that the indicated Severity corresponds to a worst-case usage scenario.\n\n### Impact\nPostgreSQL drivers (postgres64, postgres7, postgres8, postgres9).\n\n### Patches\nVulnerability is fixed in ADOdb 5.22.9 (11107d6d6e5160b62e05dff8a3a2678cf0e3a426).\n\n### Workarounds\nOnly pass controlled data to pg_insert_id() method's $fieldname parameter, or escape it with pg_escape_identifier() first.\n\n### References\n- Issue https://github.com/ADOdb/ADOdb/issues/1070\n- [Blog post](https://xaliom.blogspot.com/2025/05/from-sast-to-cve-2025-46337.html) by Marco Nappi\n\n### Credits\nThanks to Marco Nappi (@mrcnpp) for reporting this vulnerability.",
|
||||
"severity": [
|
||||
{
|
||||
"type": "CVSS_V3",
|
||||
|
||||
Reference in New Issue
Block a user