| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability has been found in code-projects Student File Management System 1.0. The affected element is an unknown function of the file /download.php of the component File Download Handler. The manipulation of the argument store_id leads to improper authorization. The attack is possible to be carried out remotely. The exploit has been disclosed to the public and may be used. |
| An issue was discovered in Blood Bank Management System 1.0 allowing authenticated attackers to perform actions with escalated privileges via crafted request to delete.php. |
| Entrust nShield Connect XC, nShield 5c, and nShield HSMi through 13.6.11, or 13.7, allow an attacker to gain access the the BIOS menu because is has no password. |
| DVP-12SE11T - Password Protection Bypass |
| A security vulnerability has been detected in campcodes School File Management System 1.0. The affected element is an unknown function of the file /save_file.php. The manipulation of the argument File leads to unrestricted upload. The attack may be initiated remotely. The exploit has been disclosed publicly and may be used. |
| Signal K Server is a server application that runs on a central hub in a boat. Versions prior to 2.19.0 expose two features that can be chained together to steal JWT authentication tokens without any prior authentication. The attack combines WebSocket-based request enumeration with unauthenticated polling of access request status. The first is Unauthenticated WebSocket Request Enumeration: When a WebSocket client connects to the SignalK stream endpoint with the `serverevents=all` query parameter, the server sends all cached server events including `ACCESS_REQUEST` events that contain details about pending access requests. The `startServerEvents` function iterates over `app.lastServerEvents` and writes each cached event to any connected client without verifying authorization level. Since WebSocket connections are allowed for readonly users (which includes unauthenticated users when `allow_readonly` is true), attackers receive these events containing request IDs, client identifiers, descriptions, requested permissions, and IP addresses. The second is Unauthenticated Token Polling: The access request status endpoint at `/signalk/v1/access/requests/:id` returns the full state of an access request without requiring authentication. When an administrator approves a request, the response includes the issued JWT token in plaintext. The `queryRequest` function returns the complete request object including the token field, and the REST endpoint uses readonly authentication, allowing unauthenticated access. An attacker has two paths to exploit these vulnerabilities. Either the attacker creates their own access request (using the IP spoofing vulnerability to craft a convincing spoofed request), then polls their own request ID until an administrator approves it, receiving the JWT token; or the attacker passively monitors the WebSocket stream to discover request IDs from legitimate devices, then polls those IDs and steals the JWT tokens when administrators approve them, hijacking legitimate device credentials. Both paths require zero authentication and enable complete authentication bypass. Version 2.19.0 fixes the underlying issues. |
| Improper host authentication vulnerability in wolfSSH version 1.4.20 and earlier clients that allows authentication bypass and leaking of clients credentials. |
| Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files into the target repository's object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a "proper" clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. |
| youlai-boot V2.21.1 is vulnerable to Incorrect Access Control. The getRoleForm function in SysRoleController.java does not perform permission checks, which may allow non-root users to directly access root roles. |
| youlai-boot V2.21.1 is vulnerable to Incorrect Access Control. The importUsers function in SysUserController.java does not perform a permission check on the current user's identity, which may allow regular users to import user data into the database, resulting in an authorization bypass vulnerability. |
| Plesk 18.0 has Incorrect Access Control. |
| A security vulnerability has been detected in code-projects College Notes Uploading System 1.0. Impacted is an unknown function of the file /dashboard/userprofile.php. The manipulation of the argument image leads to unrestricted upload. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used. |
| Plane is an an open-source project management tool. In plane.io, a guest user doesn't have a permission to access https[:]//app[.]plane[.]so/[:]slug/settings. Prior to Plane version 1.2.0, a problem occurs when the `/api/workspaces/:slug/members/` is accessible by guest and able to list of users on a specific workspace that they joined. Since the `display_name` in the response is actually the handler of the email, a malicious guest can still identify admin users' email addresses. Version 1.2.0 fixes this issue. |
| Incorrect access control in SIMICAM v1.16.41-20250725, KEVIEW v1.14.92-20241120, ASECAM v1.14.10-20240725 allows attackers to access sensitive API endpoints without authentication. |
| Incorrect access control in the /api/v1/conversations/*/files API of GT Edge AI Platform before v2.0.10 allows unauthorized attackers to access other users' uploaded files. |
| Incorrect access control in the /api/v1/conversations/*/messages API of GT Edge AI Platform before v2.0.10-dev allows unauthorized attackers to access other users' message history with AI agents. |
| Authentication Bypass Using an Alternate Path or Channel vulnerability in Drupal Authenticator Login allows Authentication Bypass.This issue affects Authenticator Login: from 0.0.0 before 2.1.8. |
| A vulnerability in the directory permissions of Cisco Desk Phone 9800 Series, Cisco IP Phone 7800 and 8800 Series, and Cisco Video Phone 8875 could allow an unauthenticated, remote attacker to write arbitrary files on an affected device.
This vulnerability is due to a lack of proper authentication controls. An attacker could exploit this vulnerability by sending a crafted request to an affected device. A successful exploit could allow the attacker to perform arbitrary file writes to specific directories in the underlying operating system.
Note: To exploit this vulnerability, Web Access must be enabled on the phone. Web Access is disabled by default. |
| Vulnerability in CodexThemes TheGem (Elementor), CodexThemes TheGem (WPBakery).This issue affects TheGem (Elementor): from n/a before 5.8.1.1; TheGem (WPBakery): from n/a before 5.8.1.1. |
| In the Linux kernel, the following vulnerability has been resolved:
smack: tcp: ipv4, fix incorrect labeling
Currently, Smack mirrors the label of incoming tcp/ipv4 connections:
when a label 'foo' connects to a label 'bar' with tcp/ipv4,
'foo' always gets 'foo' in returned ipv4 packets. So,
1) returned packets are incorrectly labeled ('foo' instead of 'bar')
2) 'bar' can write to 'foo' without being authorized to write.
Here is a scenario how to see this:
* Take two machines, let's call them C and S,
with active Smack in the default state
(no settings, no rules, no labeled hosts, only builtin labels)
* At S, add Smack rule 'foo bar w'
(labels 'foo' and 'bar' are instantiated at S at this moment)
* At S, at label 'bar', launch a program
that listens for incoming tcp/ipv4 connections
* From C, at label 'foo', connect to the listener at S.
(label 'foo' is instantiated at C at this moment)
Connection succeedes and works.
* Send some data in both directions.
* Collect network traffic of this connection.
All packets in both directions are labeled with the CIPSO
of the label 'foo'. Hence, label 'bar' writes to 'foo' without
being authorized, and even without ever being known at C.
If anybody cares: exactly the same happens with DCCP.
This behavior 1st manifested in release 2.6.29.4 (see Fixes below)
and it looks unintentional. At least, no explanation was provided.
I changed returned packes label into the 'bar',
to bring it into line with the Smack documentation claims. |
