| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Dell PowerStore contains an OS Command Injection vulnerability. An authenticated user with limited privileges could potentially exploit this vulnerability, potentially leading to privilege escalation to root on the appliance. |
| - Dependency on Vulnerable Third-Party Component vulnerability in Johnson Controls FX Server, Johnson Controls FX80, and Johnson Controls FX90 allows CAPEC‑17: Accessing, Modifying or Deleting Files.
This issue affects FX Server: before 14.10.10 and before 14.14.1; FX80: before 14.14.10 and before 14.14.1; FX90: before 14.10.10 and before 14.14.1. |
| Incorrect privilege assignment in the app token management component in Devolutions PowerShell Universal 2026.3.4 and earlier allows an authenticated user with token creation or update permissions to escalate privileges to administrator, and allows a revoked app token to be reinstated in multi-node deployments, via crafted app token requests that set an arbitrary role or revocation state. |
| Missing protection mechanism for alternate hardware interface vulnerability in Johnson Controls iSTAR Ultra and Johnson Controls iSTAR Ultra SE allows CAPEC‑554: Functionality Bypass.
This issue affects iSTAR Ultra: before 6.9.2.CU02; iSTAR Ultra SE: before 6.9.2.CU02. |
| : Improper Neutralization of Special Elements used in an OS Command vulnerability in Johnson Controls iSTAR Ultra, Johnson Controls iSTAR Ultra SE, Johnson Controls iSTAR Ultra G2, Johnson Controls iSTAR Ultra G2 SE, and Johnson Controls iSTAR Edge G2 allows : OS Command Injection.
This issue affects iSTAR Ultra: before 6.9.2.CU02; iSTAR Ultra SE: before 6.9.2.CU02; iSTAR Ultra G2: before 6.9.2.CU02; iSTAR Ultra G2 SE: before 6.9.2.CU02; iSTAR Edge G2: before 6.9.2.CU02. |
| Software installed and run as a non-privileged user may conduct improper GPU system calls through the DDK kernel module interface. Under unsupported use of the interface, a use-after-free condition may occur that can lead to kernel memory corruption, platform instability, or system reboot.
The weakness occurs when software references memory after it has been released. Accessing memory after free may result in corruption of valid data structures, unexpected program behaviour, process crashes, or execution of unintended operations. |
| Software installed and run as a non-privileged user may conduct GPU system calls to trigger an integer overflow and allow OOB writes to GPU buffers.
The integer overflow caused when mapping a GPU buffer >4GB causes corruption of array length, and can lead to kernel panics or out of bounds access. |
| Memory overflow in the management plane can lead to unpredictable or erroneous behavior or Denial of Service in Citrix NetScaler ADC and Citrix NetScaler Gateway. |
| ExcelJS through 4.4.0 contains a memory exhaustion vulnerability that allows attackers to crash applications by supplying a workbook with an unbounded image anchor column in the drawing part. Attackers can set an anchor column such as 300000000 in xl/drawings/drawing1.xml so reading getImages() anchor positions makes Worksheet.getColumn allocate millions of Column objects and abort with a heap out-of-memory error. |
| OpenEMR before 8.5.0 contains an authorization bypass vulnerability that allows authenticated users to override system-wide global configuration values by storing global-prefixed keys through library/ajax/user_settings.php. Attackers can submit lab or target parameters with global: prefixed setting names to disable audit logging, weaken password policies, or alter security-sensitive settings persistently for their sessions. |
| A flaw was found in dbus. A local attacker can exploit this vulnerability by connecting to an affected service, requesting a response, and stopping socket reads while keeping the connection open. Because the socket transport handles broken pipe write errors as retryable, the application enters a continuous retry loop. This can lead to excessive CPU consumption, resulting in a denial of service (DoS) for the target process. |
| Building a malicious package that uses cgo could bypass "#cgo LDFLAGS" validation and cause unexpected code execution at build time, or cause the go command to panic, via crafted quoting in "//go:cgo_ldflag" directives. When "cmd/cgo" generates "_cgo_gotypes.go", it quotes each "#cgo LDFLAGS" argument with strconv.Quote in a "//go:cgo_ldflag" directive, but "cmd/compile" and "cmd/go" parsed those directives by splitting on raw quote characters without handling backslash escapes or unquoting the string. This mismatch allowed disallowed linker flags or unvalidated linker search paths to be smuggled past the go command's flag checks and passed to the external linker. In addition, deduplicating LDFLAGS in the go command could panic with an out-of-bounds slice index when a prefix of the flag list matched near the end of the slice. "cmd/compile" and "cmd/go" now properly handle backslash-escaped quotes and unquote "//go:cgo_*" pragma strings with strconv.Unquote, and the slice bounds check in processCgoOutputs has been fixed. |
| Software installed and run as a non-privileged user may conduct improper GPU system calls to the execution of an error path that triggers an OOB read & write.
An error can be triggered which causes the index of the array element to be cleaned up by the error path would be outside of the array bounds. |
| The WP Ultimate CSV Importer WordPress plugin before 9.2 does not restrict the destination filename and extension, nor validate the fetched content type, when importing remote media, allowing an Administrator of a Multisite subsite to write and execute arbitrary PHP in the shared WordPress context despite not being a Network Administrator and being unable to install WP Ultimate CSV Importer WordPress plugin before 9.2 or edit files. |
| Building a malicious package that uses "//go:cgo_import_dynamic" or links against a crafted PE object on Windows could pass unsafe library arguments to the external linker. The compiler only checked the first character of the library name in "//go:cgo_import_dynamic" directives and skipped validation in cgo-generated files. In addition, on Windows, "cmd/cgo" and "cmd/link" did not validate imported DLL names extracted from PE object files before emitting "-l<name>" flags for the external linker, allowing a crafted DLL name containing ".." path traversal or special characters to reference arbitrary files on disk. The compiler now validates every character of the library name in "//go:cgo_import_dynamic" directives (including in cgo-generated files on Windows) and rejects ".." path traversal, and "cmd/cgo" and "cmd/link" reject PE imported DLL names containing path separators, "..", ":", or leading "-" or "@". |
| Building a package containing a crafted ".syso" file could bypass cgo flag validation and inject arbitrary linker flags when linking. When loading ".syso" entries from a package archive, the linker only checked for recognized host object headers (ELF, Mach-O, PE, and XCOFF) before falling through to Go object parsing. A ".syso" file beginning with a "go object" header was parsed as a Go compiler object, allowing untrusted cgo metadata directives (such as "cgo_ldflag" or "cgo_dynamic_linker") embedded in the ".syso" file to be passed to the external linker without validation. Additionally, ".syso" filenames longer than 16 bytes lost their ".syso" extension when truncated in archive headers, and unrecognized ".syso" formats forced external linking in pure-Go builds. The linker now rejects ".syso" files that are not recognized host object formats, and "cmd/go" and "cmd/pack" preserve the ".syso" suffix when truncating long archive member names. |
| Building a malicious package that uses "#cgo pkg-config:" directives could load untrusted pkg-config ".pc" files or inject unvalidated compiler and linker flags. The pkg-config flag allowlist previously permitted "--with-path=" and "--personality=", allowed "--define-variable=" values beginning with "=" or "$" (which can rewrite paths in system ".pc" files into sysroot-prefixed "-L=" or "-L$SYSROOT" linker search paths), and allowed package arguments ending in ".pc" or containing path separators or "..", which caused pkg-config to load local ".pc" files directly from the package directory. In addition, flags returned by "pkg-config --cflags" in cgoCPPFLAGS were not checked when determining whether internal linking is safe. The go command now disallows "--with-path=", "--personality=", leading "=" or "$" characters in "--define-variable=" values, and local ".pc" paths in "#cgo pkg-config:" directives, and inspects cgoCPPFLAGS when checking internal linking compatibility. |
| Building a malicious package that uses cgo could cause arbitrary code execution at link time by passing linker script files to the host linker via "#cgo LDFLAGS". Split "-Wl," flags that consume a following argument (such as "-Wl,-rpath", "-Wl,--just-symbols", and "-Wl,-undefined") previously accepted a bare second argument without a "-Wl," prefix, which the compiler driver passes directly to the linker as a positional input file. Additionally, when using GNU ld.bfd, flags such as "-framework", "-Wl,-framework", "-Wl,-undefined", "-Wl,--just-symbols", "-Wl,-R", "-Wl,-subsystem", and (on non-Darwin platforms) "-Wl,-sectcreate" could cause ld.bfd to interpret their arguments as linker scripts if they named a regular file on disk. The go command now requires a "-Wl," prefix on the second token of split "-Wl," flags (except "-Wl,-R"), verifies that these flags do not reference linker script files, and disallows bare "-Wl,--warn-backrefs-exclude". |
| On Darwin, building a malicious package that uses cgo could cause arbitrary code execution when using the Apple linker due to passing "-l to_library <path>" in a "#cgo LDFLAGS" directive. The Apple linker recombines the separated arguments "-l" and "to_library" into "-lto_library", which loads an arbitrary LTO plugin dynamic library at link time. The go command now disallows "-l" followed by "to_library" in "#cgo LDFLAGS", rejects "-lazy_library", "-lazy_framework", "-load_hidden", "-library", and "-library-path", and checks recombined "-l" arguments against disallowed linker flags and patterns. |
| When using Clang or GCC, building a malicious package that uses cgo could cause unexpected code execution at build time or write files to arbitrary directories via "-gen-*" or "-gnat*" flags in "#cgo" directives. The "-g*" wildcard in the compiler and linker flag allowlists previously matched Clang's two-argument "-gen-cdb-fragment-path <dir>" flag and GCC's two-argument "-gnatO <file>" flag, permitting compilation database fragments and sidecar output files to be written to arbitrary directories and desynchronizing flag argument parsing between the go command and the compiler driver so that subsequent arguments could be passed as unvalidated positional inputs to the linker. "-gen-*" and "-gnat*" flags are now disallowed in "#cgo" compiler and linker flags. |
