| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Adobe Experience Manager versions 6.5.23 and earlier are affected by a stored Cross-Site Scripting (XSS) vulnerability that could be abused by an attacker to inject malicious scripts into vulnerable form fields. Malicious JavaScript may be executed in a victim’s browser when they browse to the page containing the vulnerable field. |
| Allocation of Resources Without Limits or Throttling vulnerability in Legion of the Bouncy Castle Inc. BC Java bcprov on All (API modules), Legion of the Bouncy Castle Inc. BC-FJA bc-fips on All allows Excessive Allocation. This vulnerability is associated with program files https://github.com/bcgit/bc-java/blob/main/core/src/main/java/org/bouncycastle/asn1/ASN1ObjectIdenti... https://github.com/bcgit/bc-java/blob/main/core/src/main/java/org/bouncycastle/asn1/ASN1ObjectIdentifier.Java .
This issue affects BC Java: from 1.0 through 1.77; BC-FJA: from 1.0.0 through 1.0.2.5, from 2.0.0 through 2.0.1. |
| By using the "uscan" protocol provided by the eSCL specification, an attacker can discover the serial number of multi-function printers that implement the Brother-provided firmware. This serial number can, in turn, can be leveraged by the flaw described by CVE-2024-51978 to calculate the default administrator password. This flaw is similar to CVE-2024-51977, with the only difference being the protocol by which an attacker can use to learn the remote device's serial number. The eSCL/uscan vector is typically only exposed on the local network. Any discovery service that implements the eSCL specification can be used to exploit this vulnerability, and one such implementation is the runZero Explorer. Changing the default administrator password will render this vulnerability virtually worthless, since the calculated default administrator password would no longer be the correct password. |
| In the Linux kernel, the following vulnerability has been resolved:
backlight: led-bl: Add devlink to supplier LEDs
LED Backlight is a consumer of one or multiple LED class devices, but
devlink is currently unable to create correct supplier-producer links when
the supplier is a class device. It creates instead a link where the
supplier is the parent of the expected device.
One consequence is that removal order is not correctly enforced.
Issues happen for example with the following sections in a device tree
overlay:
// An LED driver chip
pca9632@62 {
compatible = "nxp,pca9632";
reg = <0x62>;
// ...
addon_led_pwm: led-pwm@3 {
reg = <3>;
label = "addon:led:pwm";
};
};
backlight-addon {
compatible = "led-backlight";
leds = <&addon_led_pwm>;
brightness-levels = <255>;
default-brightness-level = <255>;
};
In this example, the devlink should be created between the backlight-addon
(consumer) and the pca9632@62 (supplier). Instead it is created between the
backlight-addon (consumer) and the parent of the pca9632@62, which is
typically the I2C bus adapter.
On removal of the above overlay, the LED driver can be removed before the
backlight device, resulting in:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
...
Call trace:
led_put+0xe0/0x140
devm_led_release+0x6c/0x98
Another way to reproduce the bug without any device tree overlays is
unbinding the LED class device (pca9632@62) before unbinding the consumer
(backlight-addon):
echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind
echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind
Fix by adding a devlink between the consuming led-backlight device and the
supplying LED device, as other drivers and subsystems do as well. |
| In the Linux kernel, the following vulnerability has been resolved:
comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()
Syzbot identified an issue [1] in pcl818_ai_cancel(), which stems from
the fact that in case of early device detach via pcl818_detach(),
subdevice dev->read_subdev may not have initialized its pointer to
&struct comedi_async as intended. Thus, any such dereferencing of
&s->async->cmd will lead to general protection fault and kernel crash.
Mitigate this problem by removing a call to pcl818_ai_cancel() from
pcl818_detach() altogether. This way, if the subdevice setups its
support for async commands, everything async-related will be
handled via subdevice's own ->cancel() function in
comedi_device_detach_locked() even before pcl818_detach(). If no
support for asynchronous commands is provided, there is no need
to cancel anything either.
[1] Syzbot crash:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
CPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:pcl818_ai_cancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762
...
Call Trace:
<TASK>
pcl818_detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115
comedi_device_detach_locked+0x178/0x750 drivers/comedi/drivers.c:207
do_devconfig_ioctl drivers/comedi/comedi_fops.c:848 [inline]
comedi_unlocked_ioctl+0xcde/0x1020 drivers/comedi/comedi_fops.c:2178
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
... |
| In the Linux kernel, the following vulnerability has been resolved:
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was identified by the 'ioctl_sg01' test from Linux
Test Project (LTP). The following bytes were mainly observed: 0x53425355.
When USB storage devices incorrectly skip the data phase with status data,
the code extracts/validates the CSW from the sg buffer, but fails to clear
it afterwards. This leaves status protocol data in srb's transfer buffer,
such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can
lead to USB protocols leaks to user space through SCSI generic (/dev/sg*)
interfaces, such as the one seen here when the LTP test requested 512 KiB.
Fix the leak by zeroing the CSW data in srb's transfer buffer immediately
after the validation of devices that skip data phase.
Note: Differently from CVE-2018-1000204, which fixed a big leak by zero-
ing pages at allocation time, this leak occurs after allocation, when USB
protocol data is written to already-allocated sg pages. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced
When re-injecting a soft interrupt from an INT3, INT0, or (select) INTn
instruction, discard the exception and retry the instruction if the code
stream is changed (e.g. by a different vCPU) between when the CPU
executes the instruction and when KVM decodes the instruction to get the
next RIP.
As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-inject
INT3/INTO instead of retrying the instruction"), failure to verify that
the correct INTn instruction was decoded can effectively clobber guest
state due to decoding the wrong instruction and thus specifying the
wrong next RIP.
The bug most often manifests as "Oops: int3" panics on static branch
checks in Linux guests. Enabling or disabling a static branch in Linux
uses the kernel's "text poke" code patching mechanism. To modify code
while other CPUs may be executing that code, Linux (temporarily)
replaces the first byte of the original instruction with an int3 (opcode
0xcc), then patches in the new code stream except for the first byte,
and finally replaces the int3 with the first byte of the new code
stream. If a CPU hits the int3, i.e. executes the code while it's being
modified, then the guest kernel must look up the RIP to determine how to
handle the #BP, e.g. by emulating the new instruction. If the RIP is
incorrect, then this lookup fails and the guest kernel panics.
The bug reproduces almost instantly by hacking the guest kernel to
repeatedly check a static branch[1] while running a drgn script[2] on
the host to constantly swap out the memory containing the guest's TSS.
[1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a
[2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b |
| In the Linux kernel, the following vulnerability has been resolved:
comedi: multiq3: sanitize config options in multiq3_attach()
Syzbot identified an issue [1] in multiq3_attach() that induces a
task timeout due to open() or COMEDI_DEVCONFIG ioctl operations,
specifically, in the case of multiq3 driver.
This problem arose when syzkaller managed to craft weird configuration
options used to specify the number of channels in encoder subdevice.
If a particularly great number is passed to s->n_chan in
multiq3_attach() via it->options[2], then multiple calls to
multiq3_encoder_reset() at the end of driver-specific attach() method
will be running for minutes, thus blocking tasks and affected devices
as well.
While this issue is most likely not too dangerous for real-life
devices, it still makes sense to sanitize configuration inputs. Enable
a sensible limit on the number of encoder chips (4 chips max, each
with 2 channels) to stop this behaviour from manifesting.
[1] Syzbot crash:
INFO: task syz.2.19:6067 blocked for more than 143 seconds.
...
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5254 [inline]
__schedule+0x17c4/0x4d60 kernel/sched/core.c:6862
__schedule_loop kernel/sched/core.c:6944 [inline]
schedule+0x165/0x360 kernel/sched/core.c:6959
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016
__mutex_lock_common kernel/locking/mutex.c:676 [inline]
__mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760
comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868
chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414
do_dentry_open+0x953/0x13f0 fs/open.c:965
vfs_open+0x3b/0x340 fs/open.c:1097
... |
| In the Linux kernel, the following vulnerability has been resolved:
comedi: check device's attached status in compat ioctls
Syzbot identified an issue [1] that crashes kernel, seemingly due to
unexistent callback dev->get_valid_routes(). By all means, this should
not occur as said callback must always be set to
get_zero_valid_routes() in __comedi_device_postconfig().
As the crash seems to appear exclusively in i386 kernels, at least,
judging from [1] reports, the blame lies with compat versions
of standard IOCTL handlers. Several of them are modified and
do not use comedi_unlocked_ioctl(). While functionality of these
ioctls essentially copy their original versions, they do not
have required sanity check for device's attached status. This,
in turn, leads to a possibility of calling select IOCTLs on a
device that has not been properly setup, even via COMEDI_DEVCONFIG.
Doing so on unconfigured devices means that several crucial steps
are missed, for instance, specifying dev->get_valid_routes()
callback.
Fix this somewhat crudely by ensuring device's attached status before
performing any ioctls, improving logic consistency between modern
and compat functions.
[1] Syzbot report:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0
Call Trace:
<TASK>
get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline]
parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401
do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594
compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline]
comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273
__do_compat_sys_ioctl fs/ioctl.c:695 [inline]
__se_compat_sys_ioctl fs/ioctl.c:638 [inline]
__ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638
do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
... |
| The Access Manager 92xx in hardware revision K7 is based on Linux instead of Windows CE embedded in older hardware revisions. In this new hardware revision it was noticed that an SSH service is exposed on port 22. By analyzing the firmware of the devices, it was noticed that there are two users with hardcoded and weak passwords that can be used to access the devices via SSH. The passwords can be also guessed very easily. The password of at least one user is set to a random value after the first deployment, with the restriction that the password is only randomized if the configured date is prior to 2022. Therefore, under certain circumstances, the passwords are not randomized. For example, if the clock is never set on the device, the battery of the clock module has been changed, the Access Manager has been factory reset and has not received a time yet. |
| nginx-defender is a high-performance, enterprise-grade Web Application Firewall (WAF) and threat detection system engineered for modern web infrastructure. This is a configuration vulnerability affecting nginx-defender deployments. Example configuration files
config.yaml and docker-compose.yml contain default credentials (default_password: "change_me_please", GF_SECURITY_ADMIN_PASSWORD=admin123). If users deploy nginx-defender without changing these defaults, attackers with network access could gain administrative control, bypassing security protections. The issue is addressed in v1.5.0 and later. |
| content-security-policy-parser parses content security policy directives. A prototype pollution vulnerability exists in versions 0.5.0 and earlier, wherein if a policy name is called __proto__, one can override the Object prototype. This issue has been patched in version 0.6.0. A workaround involves disabling prototype method in NodeJS, neutralizing all possible prototype pollution attacks. Provide either --disable-proto=delete (recommended) or --disable-proto=throw as an argument to node to enable this feature. |
| conda-smithy is a tool for combining a conda recipe with configurations to build using freely hosted CI services into a single repository. Prior to version 3.47.1, the travis_encrypt_binstar_token implementation in the conda-smithy package has been identified as vulnerable to an Oracle Padding Attack. This vulnerability results from the use of an outdated and insecure padding scheme during RSA encryption. A malicious actor with access to an oracle system can exploit this flaw by iteratively submitting modified ciphertexts and analyzing responses to infer the plaintext without possessing the private key. This issue has been patched in version 3.47.1. |
| Actualizer is a single shell script solution to allow developers and embedded engineers to create Debian operating systems (OS). Prior to version 1.2.0, Actualizer uses OpenSSL's "-passwd" function, which uses SHA512 instead of a more suitable password hasher like Yescript/Argon2i. All Actualizer users building a full Debian Operating System are affected. Users should upgrade to version 1.2.0 of Actualizer. Existing OS deployment requires manual password changes against the alpha and root accounts. The change will deploy's Debian's yescript overriding the older SHA512 hash created by OpenSSL. As a workaround, users need to reset both `root` and "Alpha" users' passwords. |
| A denial of service (DoS) vulnerability has been identified in the JavaScript library microlight version 0.0.7. This library, used for syntax highlighting, does not limit the size of textual content it processes in HTML elements with the microlight class. When excessively large content (e.g., 100 million characters) is processed, the reset function in microlight.js consumes excessive memory and CPU resources, causing browser crashes or unresponsiveness. An attacker can exploit this vulnerability by tricking a user into visiting a malicious web page containing a microlight element with large content, resulting in a denial of service. NOTE: this is disputed by multiple parties because a large amount of memory and CPU resources is expected to be needed for content of that size. |
| A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions), RUGGEDCOM ROX MX5000RE (All versions), RUGGEDCOM ROX RX1400 (All versions), RUGGEDCOM ROX RX1500 (All versions), RUGGEDCOM ROX RX1501 (All versions), RUGGEDCOM ROX RX1510 (All versions), RUGGEDCOM ROX RX1511 (All versions), RUGGEDCOM ROX RX1512 (All versions), RUGGEDCOM ROX RX1524 (All versions), RUGGEDCOM ROX RX1536 (All versions), RUGGEDCOM ROX RX5000 (All versions). Affected devices do not properly limit access through its Built-In-Self-Test (BIST) mode.
This could allow an attacker with physical access to the serial interface to bypass authentication and get access to a root shell on the device. |
| A vulnerability has been identified in POWER METER SICAM Q100 (7KG9501-0AA01-0AA1) (All versions >= V2.60 < V2.62), POWER METER SICAM Q100 (7KG9501-0AA01-2AA1) (All versions >= V2.60 < V2.62), POWER METER SICAM Q100 (7KG9501-0AA31-0AA1) (All versions >= V2.60 < V2.62), POWER METER SICAM Q100 (7KG9501-0AA31-2AA1) (All versions >= V2.60 < V2.62), POWER METER SICAM Q200 family (All versions >= V2.70 < V2.80). Affected devices export the password for the SMTP account as plain text in the Configuration File. This could allow an authenticated local attacker to extract it and use the configured SMTP service for arbitrary purposes. |
| A vulnerability has been identified in SINUMERIK 828D PPU.4 (All versions < V4.95 SP5), SINUMERIK 828D PPU.5 (All versions < V5.25 SP1), SINUMERIK 840D sl (All versions < V4.95 SP5), SINUMERIK MC (All versions < V1.25 SP1), SINUMERIK MC V1.15 (All versions < V1.15 SP5), SINUMERIK ONE (All versions < V6.25 SP1), SINUMERIK ONE V6.15 (All versions < V6.15 SP5). The affected application improperly validates authentication for its VNC access service, allowing access with insufficient password verification.
This could allow an attacker to gain unauthorized remote access and potentially compromise system confidentiality, integrity, or availability. |
| A vulnerability has been identified in SIMOTION SCOUT TIA V5.4 (All versions), SIMOTION SCOUT TIA V5.5 (All versions), SIMOTION SCOUT TIA V5.6 (All versions < V5.6 SP1 HF7), SIMOTION SCOUT TIA V5.7 (All versions < V5.7 SP1 HF1), SIMOTION SCOUT V5.4 (All versions), SIMOTION SCOUT V5.5 (All versions), SIMOTION SCOUT V5.6 (All versions < V5.6 SP1 HF7), SIMOTION SCOUT V5.7 (All versions < V5.7 SP1 HF1), SINAMICS STARTER V5.5 (All versions), SINAMICS STARTER V5.6 (All versions), SINAMICS STARTER V5.7 (All versions < V5.7 HF2). The affected application contains a XML External Entity Injection (XXE) vulnerability while parsing specially crafted XML files. This could allow an attacker to read arbitrary files in the system. |
| A vulnerability has been identified in SIPROTEC 5 6MD84 (CP300) (All versions < V10.0), SIPROTEC 5 6MD85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 6MD86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 6MD89 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 6MU85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7KE85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SA82 (CP150) (All versions < V10.0), SIPROTEC 5 7SA86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SA87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SD82 (CP150) (All versions < V10.0), SIPROTEC 5 7SD86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SD87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SJ81 (CP150) (All versions < V10.0), SIPROTEC 5 7SJ82 (CP150) (All versions < V10.0), SIPROTEC 5 7SJ85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SJ86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SK82 (CP150) (All versions < V10.0), SIPROTEC 5 7SK85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SL82 (CP150) (All versions < V10.0), SIPROTEC 5 7SL86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SL87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SS85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7ST85 (CP300) (All versions < V10.0), SIPROTEC 5 7ST86 (CP300) (All versions < V10.0), SIPROTEC 5 7SX82 (CP150) (All versions < V10.0), SIPROTEC 5 7SX85 (CP300) (All versions < V10.0), SIPROTEC 5 7SY82 (CP150) (All versions < V10.0), SIPROTEC 5 7UM85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7UT82 (CP150) (All versions < V10.0), SIPROTEC 5 7UT85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7UT86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7UT87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7VE85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7VK87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7VU85 (CP300) (All versions < V10.0), SIPROTEC 5 Compact 7SX800 (CP050) (All versions < V10.0). Affected devices do not properly limit the bandwidth for incoming network packets over their local USB port. This could allow an attacker with physical access to send specially crafted packets with high bandwidth to the affected devices thus forcing them to exhaust their memory and stop responding to any network traffic via the local USB port. Affected devices reset themselves automatically after a successful attack. The protection function is not affected of this vulnerability. |
