| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Lack of authorisation in Deporsite by T-INNOVA. This vulnerability allows an unauthenticated attacker to change other users' profile pictures via a POST request using the parameters ‘IdPersona’ and “Foto” in ‘/ajax/TInnova_c/FotoUsuario/llamadaAjax/uploadImage’. |
| SQL injection in Sergestec's SISTICK v7.2. This vulnerability allows an attacker to retrieve, create, update, and delete databases through the 'id' parameter in '/index.php?view=ticket_detail'. |
| Inadequate access control vulnerability in Davantis DDFUSION v6.177.7, which allows unauthorised actors to retrieve perspective parameters from security camera settings by accessing “/cameras/<CAMERA_ID>/perspective”. |
| SQL injection vulnerability in the DRED virtual campus platform. This vulnerability allows an attacker to retrieve, create, update, and delete data from the database by sending a POST request using the ‘buscame’ parameter in ‘/catalogo_c/catalogo.php’. |
| KV STUDIO versions 12.23 and prior contain a buffer underflow vulnerability. If the product uses a specially crafted file, arbitrary code may be executed on the affected product. |
| A Stored Cross Site Scripting vulnerability has been found in UltimatePOS by UltimateFosters. This vulnerability is due to the lack of proper validation of user inputs via ‘/products/<PRODUCT_ID>/edit’, affecting to ‘name’ parameter via POST. The vulnerability could allow a remote attacker to send a specially crafted query to an authenticated user and steal his/her session cookies details. |
| Apache::AuthAny::Cookie v0.201 or earlier for Perl generates session ids insecurely.
Session ids are generated using an MD5 hash of the epoch time and a call to the built-in rand function. The epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage.
Predicable session ids could allow an attacker to gain access to systems. |
| Starch versions 0.14 and earlier generate session ids insecurely.
The default session id generator returns a SHA-1 hash seeded with a counter, the epoch time, the built-in rand function, the PID, and internal Perl reference addresses. The PID will come from a small set of numbers, and the epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage.
Predicable session ids could allow an attacker to gain access to systems. |
| Improper Input Validation, the returnUrl parameter in Account Security Settings lacks proper input validation, allowing attackers to redirect users to malicious websites (Open Redirect) and inject JavaScript code to perform cross site scripting attack.
The vulnerability affects Halo versions up to 2.174.101 and all versions between 2.175.1 and 2.184.21 |
| Volto is a ReactJS-based frontend for the Plone Content Management System. Versions 16.34.0 and below, 17.0.0 through 17.22.1, 18.0.0 through 18.27.1, and 19.0.0-alpha.1 through 19.0.0-alpha.5, an anonymous user could cause the NodeJS server part of Volto to quit with an error when visiting a specific URL. This issue is fixed in versions 16.34.1, 17.22.2, 18.27.2 and 19.0.0-alpha.6. |
| A vulnerability was found in VMSMan up to 20250416. It has been rated as problematic. Affected by this issue is some unknown functionality of the file /login.php. The manipulation of the argument Email with the input "><script>alert(1)</script> leads to cross site scripting. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| Stalwart is a mail and collaboration server. Versions 0.13.3 and below contain an unbounded memory allocation vulnerability in the IMAP protocol parser which allows remote attackers to exhaust server memory, potentially triggering the system's out-of-memory (OOM) killer and causing a denial of service. The CommandParser implementation enforces size limits on its dynamic buffer in most parsing states, but several state handlers omit these validation checks. This issue is fixed in version 0.13.4. A workaround for this issue is to implement rate limiting and connection monitoring at the network level, however this does not provide complete protection. |
| Clinic’s Patient Management System versions 2.0 suffers from a SQL injection vulnerability in the login page. |
| A vulnerability has been found in Redmine 6.0.0/6.0.1/6.0.2/6.0.3 and classified as problematic. This vulnerability affects unknown code of the component Custom Query Handler. The manipulation of the argument Name leads to cross site scripting. The attack can be initiated remotely. Upgrading to version 6.0.4 is able to address this issue. It is recommended to upgrade the affected component. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: dont report verifier bug for missing bpf_scc_visit on speculative path
Syzbot generated a program that triggers a verifier_bug() call in
maybe_exit_scc(). maybe_exit_scc() assumes that, when called for a
state with insn_idx in some SCC, there should be an instance of struct
bpf_scc_visit allocated for that SCC. Turns out the assumption does
not hold for speculative execution paths. See example in the next
patch.
maybe_scc_exit() is called from update_branch_counts() for states that
reach branch count of zero, meaning that path exploration for a
particular path is finished. Path exploration can finish in one of
three ways:
a. Verification error is found. In this case, update_branch_counts()
is called only for non-speculative paths.
b. Top level BPF_EXIT is reached. Such instructions are never a part of
an SCC, so compute_scc_callchain() in maybe_scc_exit() will return
false, and maybe_scc_exit() will return early.
c. A checkpoint is reached and matched. Checkpoints are created by
is_state_visited(), which calls maybe_enter_scc(), which allocates
bpf_scc_visit instances for checkpoints within SCCs.
Hence, for non-speculative symbolic execution paths, the assumption
still holds: if maybe_scc_exit() is called for a state within an SCC,
bpf_scc_visit instance must exist.
This patch removes the verifier_bug() call for speculative paths. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI/pwrctrl: Fix double cleanup on devm_add_action_or_reset() failure
When devm_add_action_or_reset() fails, it calls the passed cleanup
function. Hence the caller must not repeat that cleanup.
Replace the "goto err_regulator_free" by the actual freeing, as there
will never be a need again for a second user of this label. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: amd/sdw_utils: avoid NULL deref when devm_kasprintf() fails
devm_kasprintf() may return NULL on memory allocation failure,
but the debug message prints cpus->dai_name before checking it.
Move the dev_dbg() call after the NULL check to prevent potential
NULL pointer dereference. |
| In the Linux kernel, the following vulnerability has been resolved:
mailbox: zynqmp-ipi: Fix SGI cleanup on unbind
The driver incorrectly determines SGI vs SPI interrupts by checking IRQ
number < 16, which fails with dynamic IRQ allocation. During unbind,
this causes improper SGI cleanup leading to kernel crash.
Add explicit irq_type field to pdata for reliable identification of SGI
interrupts (type-2) and only clean up SGI resources when appropriate. |
| In the Linux kernel, the following vulnerability has been resolved:
accel/qaic: Fix bootlog initialization ordering
As soon as we queue MHI buffers to receive the bootlog from the device,
we could be receiving data. Therefore all the resources needed to
process that data need to be setup prior to queuing the buffers.
We currently initialize some of the resources after queuing the buffers
which creates a race between the probe() and any data that comes back
from the device. If the uninitialized resources are accessed, we could
see page faults.
Fix the init ordering to close the race. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: verify orphan file size is not too big
In principle orphan file can be arbitrarily large. However orphan replay
needs to traverse it all and we also pin all its buffers in memory. Thus
filesystems with absurdly large orphan files can lead to big amounts of
memory consumed. Limit orphan file size to a sane value and also use
kvmalloc() for allocating array of block descriptor structures to avoid
large order allocations for sane but large orphan files. |
