| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| CoreDNS is a DNS server that chains plugins. In versions prior to 1.14.3, the transfer plugin can select the wrong ACL stanza when both a parent zone and a more-specific subzone are configured. The longestMatch() function in plugin/transfer/transfer.go uses a lexicographic string comparison instead of an actual longest-suffix match to select the winning zone. As a result, a permissive parent-zone transfer rule can override a restrictive subzone rule depending on zone name ordering (e.g., "example.org." > "a.example.org." lexicographically). This allows an unauthorized remote client to perform AXFR/IXFR for the subzone and retrieve its full zone contents. This issue has been fixed in version 1.14.3. |
| Nornicdb is a distributed low-latency, Graph+Vector, Temporal MVCC with all sub-ms HNSW search, graph traversal, and writes. Prior to version 1.0.42-hotfix, the --address CLI flag (and NORNICDB_ADDRESS / server.host config key) is plumbed through to the HTTP server correctly but never reaches the Bolt server config. The Bolt listener therefore always binds to the wildcard address (all interfaces), regardless of what the user configures. On a LAN, this exposes the graph database — with its default admin:password credentials — to any device sharing the network. This issue has been patched in version 1.0.42-hotfix. |
| CoreDNS is a DNS server written in Go. In versions prior to 1.14.3, the gRPC, QUIC, DoH, and DoH3 transport implementations incorrectly handle TSIG authentication. For gRPC and QUIC, the server checks whether the TSIG key name exists in the configuration but never calls dns.TsigVerify() to validate the HMAC. If the key name matches a configured key, the tsigStatus field remains nil and the tsig plugin treats the request as successfully authenticated regardless of the MAC value. For DoH and DoH3, the issue is more severe: the DoHWriter.TsigStatus() method unconditionally returns nil, and the server never inspects the TSIG record at all. Any request containing a TSIG record is treated as authenticated over DoH and DoH3, even if the key name is invalid and the MAC is arbitrary.
An unauthenticated network attacker can exploit this to bypass TSIG-protected functionality such as AXFR/IXFR zone transfers, dynamic DNS updates, or other TSIG-gated plugin behavior. The DoH and DoH3 variants have a lower exploitation bar because the attacker does not need to know a valid TSIG key name.
This issue has been fixed in version 1.14.3. As a workaround, disable gRPC, QUIC, DoH, and DoH3 listeners where TSIG authentication is required, or restrict network-level access to affected transport ports to trusted sources only. |
| pgx is a PostgreSQL driver and toolkit for Go. Prior to version 5.9.2, SQL injection can occur when the non-default simple protocol is used, a dollar quoted string literal is used in the SQL query, that string literal contains text that would be would be interpreted as a placeholder outside of a string literal, and the value of that placeholder is controllable by the attacker. This issue has been patched in version 5.9.2. |
| Flarum is open-source forum software. Prior to versions 1.8.16 and 2.0.0-rc.1, Flarum's patch for CVE-2023-27577 restricted the @import and data-uri() LESS features in the custom_less setting, but the same restriction was never applied to other settings registered as LESS config variables (for example theme_primary_color and theme_secondary_color, as well as any key registered via Extend\Settings::registerLessConfigVar()). Those values are interpolated verbatim into the LESS source at compile time, allowing an authenticated administrator to craft a theme-color value that injects an arbitrary @import directive into the compiled forum.css. Because the underlying LESS parser honours @import (inline) '<path>', an attacker can read arbitrary files reachable by the PHP process (local file inclusion) or trigger outbound HTTP(S) requests (server-side request forgery). This issue has been patched in versions 1.8.16 and 2.0.0-rc.1. |
| A malicious module proxy can exploit a flaw in the go command's validation of module checksums to bypass checksum database validation. This vulnerability affects any user using an untrusted module proxy (GOMODPROXY) or checksum database (GOSUMDB). A malicious module proxy can serve altered versions of the Go toolchain. When selecting a different version of the Go toolchain than the currently installed toolchain (due to the GOTOOLCHAIN environment variable, or a go.work or go.mod with a toolchain line), the go command will download and execute a toolchain provided by the module proxy. A malicious module proxy can bypass checksum database validation for this downloaded toolchain. Since this vulnerability affects the security of toolchain downloads, setting GOTOOLCHAIN to a fixed version is not sufficient. You must upgrade your base Go toolchain. The go tool always validates the hash of a toolchain before executing it, so fixed versions will refuse to execute any cached, altered versions of the toolchain. The go tool trusts go.sum files to contain accurate hashes of the current module's dependencies. A malicious proxy exploiting this vulnerability to serve an altered module will have caused an incorrect hash to be recorded in the go.sum. Users who have configured a non-trusted GOPROXY can determine if they have been affected by running "rm go.sum ; go mod tidy ; go mod verify", which will revalidate all dependencies of the current module. The specific flaw in more detail: The go command consults the checksum database to validate downloaded modules, when a module is not listed in the go.sum file. It verifies that the module hash reported by the checksum database matches the hash of the downloaded module. If, however, the checksum database returns a successful response that contains no entry for the module, the go command incorrectly permitted validation to succeed. A module proxy may mirror or proxy the checksum database, in which case the go command will not connect to the checksum database directly. Checksums reported by the checksum database are cryptographically signed, so a malicious proxy cannot alter the reported checksum for a module. However, a proxy which returns an empty checksum response, or a checksum response for an unrelated module, could cause the go command to proceed as if a downloaded module has been validated. |
| In OpenStack Cyborg before 16.0.1, the Accelerator Request (ARQ) API does not enforce project ownership at any layer. The project_id column in the database is never populated (NULL for every ARQ), database queries have no project filtering, and policy checks are self-referential (the authorize_wsgi decorator compares the caller's project_id with itself rather than the target resource). Any authenticated non-admin user can complete various actions such as deleting ARQs bound to other projects' instances, aka cross-tenant denial of service. |
| An exploitable SQL injection vulnerability exists in the authenticated part of ERPNext v10.1.6. Specially crafted web requests can cause SQL injections resulting in data compromise. The employee and sort_order parameter can be used to perform an SQL injection attack. An attacker can use a browser to trigger these vulnerabilities, and no special tools are required. |
| An exploitable SQL injection vulnerability exists in the authenticated part of ERPNext v10.1.6. Specially crafted web requests can cause SQL injections resulting in data compromise. The sort_by and start parameter can be used to perform an SQL injection attack. An attacker can use a browser to trigger these vulnerabilities, and no special tools are required. |
| An exploitable SQL injection vulnerability exists in the authenticated part of ERPNext v10.1.6. Specially crafted web requests can cause SQL injections resulting in data compromise. The order_by parameter can be used to perform an SQL injection attack. An attacker can use a browser to trigger these vulnerabilities, and no special tools are required. |
| An exploitable SQL injection vulnerability exists in the authenticated part of ERPNext v10.1.6. Specially crafted web requests can cause SQL injections resulting in data compromise. The searchfield parameter can be used to perform an SQL injection attack. An attacker can use a browser to trigger these vulnerabilities, and no special tools are required. |
| OpenStack Cyborg before 16.0.1 uses rule:allow (check_str='@') as the default policy for multiple API endpoints. This unconditionally authorizes any request carrying a valid Keystone token regardless of roles, project membership, or scope. An authenticated user with zero role assignments can complete various actions such as reprogramming FPGA bitstreams on arbitrary compute nodes via agent RPC. |
| The socket connection handler in aswArPot.sys in the Avast and AVG Windows Anti Rootkit driver before 22.1 allows local attackers to execute arbitrary code in kernel mode or cause a denial of service (memory corruption and OS crash) due to a double fetch vulnerability at aswArPot+0xc4a3. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: 8822b: Avoid WARNING in rtw8822b_config_trx_mode()
rtw8822b_set_antenna() can be called from userspace when the chip is
powered off. In that case a WARNING is triggered in
rtw8822b_config_trx_mode() because trying to read the RF registers
when the chip is powered off returns an unexpected value.
Call rtw8822b_config_trx_mode() in rtw8822b_set_antenna() only when
the chip is powered on.
------------[ cut here ]------------
write RF mode table fail
WARNING: CPU: 0 PID: 7183 at rtw8822b.c:824 rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b]
CPU: 0 UID: 0 PID: 7183 Comm: iw Tainted: G W OE 6.17.5-arch1-1 #1 PREEMPT(full) 01c39fc421df2af799dd5e9180b572af860b40c1
Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: LENOVO 82KR/LNVNB161216, BIOS HBCN18WW 08/27/2021
RIP: 0010:rtw8822b_config_trx_mode.constprop.0+0x835/0x840 [rtw88_8822b]
Call Trace:
<TASK>
rtw8822b_set_antenna+0x57/0x70 [rtw88_8822b 370206f42e5890d8d5f48eb358b759efa37c422b]
rtw_ops_set_antenna+0x50/0x80 [rtw88_core 711c8fb4f686162be4625b1d0b8e8c6a5ac850fb]
ieee80211_set_antenna+0x60/0x100 [mac80211 f1845d85d2ecacf3b71867635a050ece90486cf3]
nl80211_set_wiphy+0x384/0xe00 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda]
? netdev_run_todo+0x63/0x550
genl_family_rcv_msg_doit+0xfc/0x160
genl_rcv_msg+0x1aa/0x2b0
? __pfx_nl80211_pre_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda]
? __pfx_nl80211_set_wiphy+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda]
? __pfx_nl80211_post_doit+0x10/0x10 [cfg80211 296485ee85696d2150309a6d21a7fbca83d3dbda]
? __pfx_genl_rcv_msg+0x10/0x10
netlink_rcv_skb+0x59/0x110
genl_rcv+0x28/0x40
netlink_unicast+0x285/0x3c0
? __alloc_skb+0xdb/0x1a0
netlink_sendmsg+0x20d/0x430
____sys_sendmsg+0x39f/0x3d0
? import_iovec+0x2f/0x40
___sys_sendmsg+0x99/0xe0
? refill_obj_stock+0x12e/0x240
__sys_sendmsg+0x8a/0xf0
do_syscall_64+0x81/0x970
? do_syscall_64+0x81/0x970
? ksys_read+0x73/0xf0
? do_syscall_64+0x81/0x970
? count_memcg_events+0xc2/0x190
? handle_mm_fault+0x1d7/0x2d0
? do_user_addr_fault+0x21a/0x690
? exc_page_fault+0x7e/0x1a0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
---[ end trace 0000000000000000 ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Return queued buffers on start_streaming() failure
Return buffers if streaming fails to start due to uvc_pm_get() error.
This bug may be responsible for a warning I got running
while :; do yavta -c3 /dev/video0; done
on an xHCI controller which failed under this workload.
I had no luck reproducing this warning again to confirm.
xhci_hcd 0000:09:00.0: HC died; cleaning up
usb 13-2: USB disconnect, device number 2
WARNING: CPU: 2 PID: 29386 at drivers/media/common/videobuf2/videobuf2-core.c:1803 vb2_start_streaming+0xac/0x120 |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: Workaround SQM/PSE stalls by disabling sticky
NIX SQ manager sticky mode is known to cause stalls when multiple SQs
share an SMQ and transmit concurrently. Additionally, PSE may deadlock
on transitions between sticky and non-sticky transmissions. There is
also a credit drop issue observed when certain condition clocks are
gated.
work around these hardware errata by:
- Disabling SQM sticky operation:
- Clear TM6 (bit 15)
- Clear TM11 (bit 14)
- Disabling sticky → non-sticky transition path that can deadlock PSE:
- Clear TM5 (bit 23)
- Preventing credit drops by keeping the control-flow clock enabled:
- Set TM9 (bit 21)
These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this
configuration the SQM/PSE maintain forward progress under load without
credit loss, at the cost of disabling sticky optimizations. |
| In the Linux kernel, the following vulnerability has been resolved:
media: chips-media: wave5: Fix PM runtime usage count underflow
Replace pm_runtime_put_sync() with pm_runtime_dont_use_autosuspend() in
the remove path to properly pair with pm_runtime_use_autosuspend() from
probe. This allows pm_runtime_disable() to handle reference count cleanup
correctly regardless of current suspend state.
The driver calls pm_runtime_put_sync() unconditionally in remove, but the
device may already be suspended due to autosuspend configured in probe.
When autosuspend has already suspended the device, the usage count is 0,
and pm_runtime_put_sync() decrements it to -1.
This causes the following warning on module unload:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 963 at kernel/kthread.c:1430
kthread_destroy_worker+0x84/0x98
...
vdec 30210000.video-codec: Runtime PM usage count underflow! |
| i18next-locize-backend is a simple i18next backend for locize.com which can be used in Node.js, in the browser and for Deno. Prior to version 9.0.2, i18next-locize-backend interpolates lng, ns, projectId, and version directly into the configured loadPath / privatePath / addPath / updatePath / getLanguagesPath URL templates with no path-component validation and no encoding. When an application exposes any of these values to user-controlled input (?lng= / ?ns= query parameters via i18next-browser-languagedetector, cookies, request headers, or a URL-derived projectId), a crafted value can change the structure of the outgoing request URL. Affected call sites in lib/index.js (pre-patch): the interpolate() helper is used at the five URL-build sites — _readAny/read (line 415 for private, 426 for public), getLanguages (lines 271 and 296), and writePage (lines 616 and 622) for the missing-key and update POST paths. The helper interpolate in lib/utils.js substitutes raw values with no encoding. This issue has been patched in version 9.0.2. |
| i18next-fs-backend is a backend layer for i18next using in Node.js and for Deno to load translations from the filesystem. Prior to version 2.6.4, i18next-fs-backend substitutes the lng and ns options directly into the configured loadPath / addPath templates and then read / write the resulting file from disk. The interpolation is unencoded and unvalidated, so a crafted lng or ns value — containing .., a path separator, a control character, a prototype key, or simply an unexpectedly long string — allows an attacker who can influence either value to read or overwrite files outside the intended locale directory. When lng / ns are derived from untrusted input (request-scoped i18next instances behind an HTTP layer such as i18next-http-middleware, or any framework that lets the end user pick the language via query string, cookie, or header), a single request such as ?lng=../../../../etc/passwd causes the backend to attempt to read that path. This issue has been patched in version 2.6.4. |
| OmniFaces is a utility library for Faces. Prior to versions 1.14.2, 2.7.32, 3.14.16, 4.7.5, and 5.2.3, there is a server-side EL injection leading to Remote Code Execution (RCE). This affects applications that use CDNResourceHandler with a wildcard CDN mapping (e.g. libraryName:*=https://cdn.example.com/*). An attacker can craft a resource request URL containing an EL expression in the resource name, which is evaluated server-side. This issue has been patched in versions 1.14.2, 2.7.32, 3.14.16, 4.7.5, and 5.2.3. |
