Export limit exceeded: 391629 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (391632 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-86765 | 1 Snipeitapp | 1 Snipe-it | 2026-09-14 | 6.5 Medium |
| Snipe-IT versions before 8.7.0 fail to enforce checkout authorization when assignment fields are submitted to the asset update endpoint. Authenticated users with edit permission but explicitly denied checkout permission can reassign assets, bypass check-in procedures, and alter custody records by submitting assigned_user, assigned_asset, or assigned_location parameters to PATCH /api/v1/hardware/{id}. | ||||
| CVE-2026-86760 | 2 Grokability, Snipeitapp | 2 Snipe-it, Snipe-it | 2026-09-14 | 5.4 Medium |
| Snipe-IT versions 8.2.0 through 8.6.x (fixed in 8.7.0) contain an incorrect authorization flaw in app/Http/Controllers/Users/UsersController::update(). The single-user edit route assigned the activated field from the request payload before evaluating the canEditAuthFields authorization gate, so an authenticated non-admin user holding the users.edit permission in the target's company scope can submit a full valid PUT request to /users/{id} and toggle the activated flag on any user, including admin and superuser accounts. Deactivating an admin locks that account out of the application until another admin or superuser re-enables it. Only the activated field is affected; username, email, password and permissions remain protected by the gate, no data is disclosed, and the API (Api\UsersController::update) and bulk-edit paths are not affected. | ||||
| CVE-2026-86755 | 2 Grokability, Snipeitapp | 2 Snipe-it, Snipe-it | 2026-09-14 | 5.4 Medium |
| Snipe-IT versions 4.2.0 through 8.6.3 expose Laravel Passport's auto-registered personal-access-token routes (GET, POST, DELETE /oauth/personal-access-tokens*) with only 'web' and 'auth:web' middleware, without the self.api permission gate that Snipe-IT enforces on its own token endpoints (/account/api and /api/v1/account/personal-access-tokens). Any user with a valid web session and the corresponding CSRF token can POST to /oauth/personal-access-tokens and mint a long-lived bearer token for their own account, even when an administrator has denied the self.api permission. The issued token is still subject to existing per-endpoint authorization policies, so this is not a privilege escalation; it defeats the administrative control intended to block API/scripted access at the user's own permission level. Fixed in 8.7.0 (commit 3f74b8c), which registers overriding routes wrapped in the can:self.api middleware. | ||||
| CVE-2026-86750 | 1 Snipeitapp | 1 Snipe-it | 2026-09-14 | 7.7 High |
| Snipe-IT versions <= 8.6.3 (fixed in 8.7.0) do not validate company assignment authorization before persisting user records via the REST API. In Api\UsersController::store() and ::update(), the user record is filled from the request and saved before the requested company_id / company_ids[] values are filtered against the actor's permitted companies (Company::getIdsForCurrentUser()). On installs using Full Multiple Companies Support (FMCS), a non-superuser holding users.create (or users.edit on a target user) can submit company identifiers for companies outside their scope — including a mix of permitted and foreign ids — causing the account row to be committed to the database before authorization is checked. Where null_company_is_floater=1 is set, the post-hoc filter leaves an empty company pivot and the account is persisted as a "floater" with cross-company visibility, allowing creation or relocation of user accounts across tenant boundaries. | ||||
| CVE-2026-86740 | 2 Grokability, Snipeitapp | 2 Snipe-it, Snipe-it | 2026-09-14 | 3.8 Low |
| Snipe-IT before 8.7.0 fails to check the return value of Storage::delete() in UploadedFilesController::destroy() and Api\\UploadedFilesController::destroy(), allowing deletion requests to report success while files remain on disk. Administrators performing attachment deletions receive success responses and see files hidden from listings, but the physical files persist on disk and remain accessible to anyone with filesystem or backup access. | ||||
| CVE-2026-86201 | 1 Pmmp | 1 Pocketmine-mp | 2026-09-14 | 7.5 High |
| PocketMine-MP before 5.41.1 contains a denial of service vulnerability in LoginPacket processing where large or complex structures in unknown clientData JWT properties cause excessive logging without sanitization. Attackers can send crafted LoginPackets with deeply nested or massive object structures to trigger out-of-memory conditions and crash the server. | ||||
| CVE-2026-86142 | 1 Xmlsoft | 1 Libxml2 | 2026-09-14 | 6.9 Medium |
| In libxml2 before 2.15.4, there is a heap-based buffer overflow in xmlXPtrEvalXPtrPart because of xmlXPtrEval xpointer length saturation. | ||||
| CVE-2026-86137 | 1 Xmlsoft | 1 Libxml2 | 2026-09-14 | 2.9 Low |
| In libxml2 before 2.15.4, xmlFAParsePosCharGroup has an out-of-bounds read, aka an out-of-bounds read in the NXT macro in xmlregexp. | ||||
| CVE-2026-85593 | 1 Phpmyfaq | 1 Phpmyfaq | 2026-09-14 | 5.4 Medium |
| phpMyFAQ versions before 4.1.8 contain a stored cross-site scripting vulnerability in FaqHelper::convertOldInternalLinks() that calls html_entity_decode() on sanitized FAQ content, reversing entity-encoding protection. Authenticated users with FAQ editing privileges can inject JavaScript payloads that execute in the browsers of all users viewing the affected FAQ pages. | ||||
| CVE-2026-85588 | 2 Phpmyfaq, Thorsten | 2 Phpmyfaq, Phpmyfaq | 2026-09-14 | N/A |
| phpMyFAQ versions before 4.1.8 include live TOTP shared secrets in plaintext within user data export ZIP files. Attackers obtaining exported archives can extract the TOTP seed and generate valid one-time codes to bypass two-factor authentication. | ||||
| CVE-2026-85578 | 2 B3log, Siyuan | 2 Siyuan, Siyuan | 2026-09-14 | 6.5 Medium |
| SiYuan through 3.8.1 contains an authorization bypass vulnerability in the /api/file/getFile endpoint that allows readers to retrieve files from notebooks explicitly configured as Visible:false. Attackers with reader role can access private workspace files including notebook metadata and internal configuration by knowing the hidden notebook identifier and file path. | ||||
| CVE-2026-85507 | 1 Freeipmi | 1 Freeipmi | 2026-09-14 | 9.8 Critical |
| ipmi-oem in FreeIPMI before 1.6.19 has a stack-based buffer overflow in _output_dell_system_info_cmc_info in ipmi-oem/ipmi-oem-dell.c (cmc-info subcommand to dell get-system-info). | ||||
| CVE-2026-85453 | 1 Themoos | 1 Core-moos | 2026-09-14 | 6.1 Medium |
| MOOS core-moos through 10.4.0 fails to escape database contents when rendering MOOSDB HTTP pages, allowing attackers to inject malicious scripts. Any MOOS publisher can set variable values containing script payloads that execute in the browser of operators viewing the web interface. | ||||
| CVE-2026-85448 | 1 Moos-ivp | 1 Moos-ivp | 2026-09-14 | 7.5 High |
| MOOS-IvP uFldShoreBroker through 24.8.1 fails to limit the number of claimed communities stored in parallel vectors within ShoreBroker::handleMailNodePing(). A single publisher can supply unbounded distinct community names to grow retained state and per-pass work without limit, causing memory exhaustion and performance degradation. | ||||
| CVE-2026-85443 | 1 Themoos | 1 Core-moos | 2026-09-14 | 7.5 High |
| MOOS core-moos through 10.4.0 contains a denial of service vulnerability in MOOSCommServer::ListenLoop() where the accept thread performs a blocking receive without timeout during the wire-protocol handshake. An attacker can open a TCP connection to the MOOSDB port and send no data, causing the accept thread to block indefinitely while holding the socket-list lock, preventing all subsequent client connections. | ||||
| CVE-2026-85438 | 1 Moos-ivp | 1 Moos-ivp | 2026-09-14 | 9.8 Critical |
| MOOS-IvP through 24.8.1 contains a buffer overflow vulnerability in StringToIvPFunction() where dimension, piece, and degree counts from encoded BHV_IPF payloads are used as allocation sizes and loop bounds without validation. Attackers can supply crafted payloads with mismatched dimension values to write attacker-controlled doubles past the end of the IvPBox weight array, causing memory corruption and potential code execution. | ||||
| CVE-2026-85433 | 1 Themoos | 1 Essential-moos | 2026-09-14 | 9.8 Critical |
| MOOS essential-moos pShare through 10.0.1 fails to properly authorize PSHARE_CMD messages, allowing any publisher to reconfigure network routes and listeners at runtime. Attackers can send crafted PSHARE_CMD messages with cmd=output or cmd=input parameters to open new listeners on arbitrary addresses and redirect or duplicate bus traffic to attacker-controlled destinations. | ||||
| CVE-2026-85428 | 1 Themoos | 1 Core-moos | 2026-09-14 | 9.8 Critical |
| MOOS core-moos through 10.4.0 contains an authentication bypass vulnerability in the optional MOOSDB HTTP server that allows unauthenticated clients to write variables. Attackers can send HTTP requests with variable names and values to the MOOSDB HTTP server port to modify MOOS variables including actuator and override commands without authentication. | ||||
| CVE-2026-85394 | 2 Mpdavis, Python-jose Project | 2 Python-jose, Python-jose | 2026-09-14 | 9.1 Critical |
| python-jose through 3.5.0 fails to properly validate asymmetric keys in HMAC initialization, accepting DER-encoded public keys that lack PEM armor or SSH prefixes. Attackers holding the service's public key can forge HS256 tokens that pass verification when algorithms are not explicitly restricted. This is an incomplete fix for CVE-2024-33663. | ||||
| CVE-2026-85389 | 1 Worklenz | 1 Worklenz | 2026-09-14 | 6.5 Medium |
| Worklenz before 3.0.0 fails to verify task ownership by organization when resolving task-scoped API endpoints, allowing authenticated users to access another tenant's task data. Attackers can query task endpoints with arbitrary task UUIDs to retrieve work logs, comments, attachments, and project insights belonging to other organizations. | ||||