An unauthenticated information disclosure in tsi-coop tsi-dpdp-cms versions 0.5.2 and earlier lets a remote attacker map the internal API parameter schema by sending a valid `_func` value with required fields omitted; the server's JSON schema validator runs before authentication and replies with a 400 error naming every missing field (for example `required property 'fiduciary_id' not found`). The leak is confined to internal parameter/field metadata for the admin, DPO and client APIs (job, API-key, operator and ROPA functions) and does not expose stored data, tokens, or permit writes. Publicly available exploit code exists, and the vendor released a fixed version (v0.5.3) after early coordinated contact; this is a moderate, not critical, priority issue.
Unauthenticated remote attackers can delete arbitrary user accounts in SEMCMS through version 5.0 by hitting the administrative endpoint /admin/SEMCMS_User.php with the parameters Class=Deleted&CF=user, which performs the deletion without enforcing the authorization check that should gate it (CWE-285). Exploitation requires only network reachability to the admin interface - no credentials, no user interaction, and no special configuration - and publicly available exploit code exists (a GitHub proof-of-concept targeting SEMCMS PHP V5.0), though there is no evidence of confirmed active exploitation in the wild. Impact is limited to integrity and availability of user records (account deletion), with no confidentiality, code-execution, or lateral-movement component, and the vendor did not respond to disclosure, so no official fix has been identified.
Unauthenticated SQL injection in the krupalshah EmployeeRecruitmentSystem admin registration handler (source/adminregister.php) allows remote attackers to manipulate backend database queries through crafted input to the registration form. Per the assessed vector (AV:N/AC:L/PR:N/UI:N), no credentials or user interaction are required, so any internet-exposed instance running the project is directly attackable, though impact is bounded to low confidentiality, integrity, and availability loss (CVSS 3.1 base 5.5-style, CVSS 4.0 score 5.5 with E:P). Publicly available exploit code exists (referenced from a GitHub CVE issue and VulDB submission 963381), but this CVE is not confirmed as actively exploited (no CISA KEV listing); EPSS data was not provided. The practical risk is driven less by exploitation difficulty than by exposure: the project is an abandoned, unsupported, rolling-release GitHub repository with no tagged versions.
SQL injection in krupalshah EmployeeRecruitmentSystem (commit 922ff6d and earlier) allows remote unauthenticated attackers to inject arbitrary SQL through the email or password parameter of the login handler at source/loginprocessing.php. The flaw arises from direct use of mysql_query() without parameterization, enabling read or modification of backend database contents. Publicly available exploit code exists, and because the project is an unmaintained rolling release, no vendor patch or supported version is available.
Argument injection in the DDNS configuration handler of the Netcore NR268 consumer router (firmware 1.7.121109) lets an authenticated, low-privilege user manipulate the Hostname parameter sent to /router/DDNSset.cgi, which is then passed unsanitized into an execvp call and can result in arbitrary command execution on the device. Because the CVSS vector shows PR:L, the attacker must first hold valid low-level credentials or a session on the device web interface, and the router's management interface must be reachable - exposure is far greater where the admin UI is internet-facing or default credentials remain unchanged. No vendor patch has been identified at time of analysis and no public exploit code has been confirmed, though the flaw is documented in a public GitHub write-up and a VulDB entry, making details discoverable.
Authentication bypass in ((OTRS)) Community Edition 6.x and earlier lets an unauthenticated remote attacker impersonate any existing agent or customer account when HTTP Basic Authentication is the configured authentication backend. Because the CGI/mod_perl deployment maps an attacker-supplied 'Remote-User' request header into the HTTP_REMOTE_USER environment variable, OTRS treats that header value as an already-authenticated username and skips password verification, after which the Generic Interface can be accessed with the impersonated account's privileges. Exploitation is not unconditional: it requires Basic Auth to be the active backend, a CGI/mod_perl (not Mojolicious/Hypnotoad) deployment, and knowledge of a valid target username, which is why an independent assessment rates the attack complexity as High (AC:H) rather than the vendor's AC:L, and no public exploit code was identified at time of analysis. OTRS 7 and later are unaffected by this vector.
Unauthenticated remote attackers can seize global super-admin control of Rapyd Admin installations running versions 9.0.0 through 9.19.x, because the framework's setup installer seeds a hard-coded administrator account (admin@laravel, password 'admin') that grants the highest privilege level in the application. The account is silently re-created on every execution of the `rpd:make` artisan command, so an operator who previously changed the password or removed the account can have the known credential restored without warning, and a successful login bypasses per-record authorization checks and multi-tenant scoping entirely. VulnCheck disclosed the issue with full source references, no public exploit code was identified at time of analysis, and no evidence of confirmed active exploitation (CISA KEV) is present; the vendor shipped the fix in v9.20.0, which creates the first admin once with a random password and never re-seeds it.
Authentication bypass in the Grav Login OAuth plugin before 1.4.3 lets unauthenticated remote attackers derive valid credentials for OAuth-provisioned accounts and take administrative control. The plugin assigns each auto-provisioned user a deterministic '<provider>.<id>' username and an unsalted MD5 hash of the provider identifier as the password, and it leaves password login enabled; anyone who learns or guesses the provider identifier can reproduce the login. No public exploit identified at time of analysis; the vendor-assigned CVSS 4.0 score is 9.3 Critical and the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
Authentication bypass in ZITADEL 4.x before 4.19.2 and 3.x through 3.4.15 lets an authenticated attacker with organization-administrator permission register a SAML identity provider using their own signing key and then obtain authenticated sessions as any user linked to a different SAML provider on the same instance, including users in other organizations. The flaw stems from the SAML identity-provider intent callback verifying the assertion signature against the provider named in the request URL while resolving the user from the login intent without confirming the two match. This is a genuine high-priority vulnerability, though not a 'spray-and-pray' internet-wide threat; exploitation requires the org-admin prerequisite and that victims authenticate via SAML identity providers. No public exploit identified at time of analysis, and a vendor-released patch exists (4.19.2 and later for 4.x; a fix beyond 3.4.15 for 3.x).
Schema-level and Query/Mutation type-level @authentication directives are silently ignored for top-level @cypher fields in @neo4j/graphql versions up to and including 7.6.3, letting unauthenticated remote callers invoke those fields and run the embedded Cypher statements with the GraphQL service account's privileges, which may permit reading and modifying data. Only @authentication placed directly on the individual @cypher field is enforced, so applications relying on schema- or type-level protection are exposed while those annotating each field individually are not. No public exploit code has been identified at time of analysis, and the vendor has released 7.6.4 as the fix.
Qexo instances running versions 4.0.0 through any release before 4.2.0 expose the /api/init_step/ initialization endpoint without authentication or a setup-completion guard, allowing an unauthenticated attacker who supplies a CSRF token harvested from any public page of the instance to restart the setup flow and, in the same interaction, read back stored PROVIDER configuration such as service credentials. The CNA rates this 9.3 (Critical, CVSS 4.0) while our independent CVSS 3.1 assessment scores it AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N, reflecting that the integrity impact is a forced re-entry into initialization rather than arbitrary data modification, and that the confidentiality loss only materializes on instances that have already stored provider secrets (for example a Vercel token or image-bed credentials). No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in Qexo 4.2.0.
Missing authorization checks in jshERP through 3.6 let any authenticated low-privilege user create tenant-wide master data - settlement accounts, products with initial stock, departments, units, and dictionary entries - because the add and import endpoints authenticate the caller but never verify role or permission. Publicly available exploit code exists in the form of PoC scripts (poc_master_data_write_authorization.py, poc_dictionary_and_config_write.py, poc_global_config_and_enumeration.py, poc_material_dictionary_write.py) that demonstrate the abuse against endpoints such as /account/add, /material/add, and /material/importExcel. The impact is bounded to data integrity within the attacker's own tenant (no confidentiality or availability loss) and requires a valid low-privilege login, making this a moderate-severity broken-access-control issue rather than a critical priority; NVD rates it 5.3 while our independent assessment is consistent with a moderate, integrity-only impact.
Broken access control in TDuck Survey Form through 6.0 allows any authenticated user to inject attacker-chosen fields onto another user's public survey fill page by abusing the batch field-creation endpoint POST /user/form/item/batch/create. Because the server validates ownership only against the first element of the submitted array, an attacker can seed the request with a form they legitimately own and append victim entries keyed by the victim's formKey, which is exposed on the form's public fill page. Publicly available exploit code exists (a Python PoC is published), and exploitation is limited to integrity impact (VI:L) with no confidentiality or availability effect; no confirmed active exploitation (CISA KEV) has been reported.
Authenticated users of jshERP through 3.6 can bypass the depot_flag warehouse restriction to read stock levels, batch numbers, sales figures and priced bill lines from warehouses they are not assigned to, by supplying arbitrary depotId or depotIds parameters to endpoints such as /depotItem/getMaterialDepotStockByParam. Only a low-privileged account inside the target tenant is required (CVSS 3.1 PR:L, read-only C:L impact, no integrity or availability effect), and publicly available exploit code exists, though there is no indication of confirmed active exploitation. Exposure is confined to cross-warehouse data segregation within a single tenant, so single-warehouse or single-operator deployments where no segregation is configured gain no practical advantage from the flaw.
Audit log tampering in jshERP through 3.6 allows any authenticated user, regardless of privilege level, to forge, alter, or erase audit log entries via the /log/add, /log/update, /log/delete, and /log/deleteBatch endpoints. This medium-severity integrity and repudiation issue (CVSS 3.1 base 5.3) lets attackers hide malicious activity or fabricate evidence, and publicly available exploit code exists. Exploitation requires a valid low-privilege session; no admin role or special configuration is needed, but unauthenticated remote exploitation is not possible.
MoguBlog through 6.2 fails to bind network-disk delete operations to the requesting administrator's own account, allowing any authenticated administrator to destroy files and folders belonging to other administrators by submitting their file or folder uid to POST /networkDisk/deleteFile or /networkDisk/batchDeleteFile. The impact is limited to integrity and availability of stored objects (no confidentiality loss) and is constrained by the requirement that the instance has more than one administrator account and that the attacker knows or can enumerate the victim's uid; the exploit is authenticated (PR:L per the assessed vector), requires no user interaction, and works against all three supported storage backends (local disk, Qiniu, MinIO). Publicly available exploit code exists, but there is no indication of confirmed active exploitation, and the severity is moderate rather than critical. A single-administrator deployment has no other admin whose files could be targeted, which materially limits real-world exposure.
jshERP through 3.6 lets any authenticated user whose role is scoped to personal- or department-level data export the complete supplier, customer and member dataset by calling GET /supplier/exportExcel, which omits the role data-scope filter enforced by /supplier/list. The exposed fields include contacts, phone numbers, tax numbers, bank accounts and balances - a broad, tenant-wide confidentiality breach that a low-privileged account can trigger with a single HTTP request; publicly available exploit code exists, and there is no confirmed active exploitation reported. Rated CVSS 4.0 base 5.3 (assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), this is a medium-severity, read-only information-disclosure flaw: no privilege escalation, code execution, or data modification results, and its practical impact depends on multi-role deployments where data-scope restrictions are actually configured.
An authorization bypass in jshERP through 3.6 lets any authenticated user - even one whose data scope is restricted to personal or department-level records - read other users' purchase, sales, and inventory bills by inserting a purchaseStatus=0 value into the search JSON of a GET /depotHead/list request. The presence of that single parameter causes DepotHeadService.select to omit the creator/owner filter, returning tenant-wide depot head records instead of only the caller's own. Publicly available exploit code exists (a VulnCheck-published PoC script), though there is no KEV-listed active exploitation and the assessed CVSS 3.1 score of 5.3 reflects confidentiality-only impact (C:L, I:N, A:N) requiring a low-privilege authenticated session, making this a moderate-severity information-disclosure issue best addressed by insiders or attackers who already hold credentials.
Authenticated users of jshERP through version 3.6 can create inventory bills that are already in an audited/approved state by submitting status=1 in the body of POST /depotHead/addDepotHeadAndDetail, sidestepping the application's audit permission check and multi-level approval workflow. The flaw is a missing-authorization issue (CWE-862) in which the server trusts a client-supplied status field instead of enforcing approval rights; any low-privilege account able to authenticate and reach the depot-head creation endpoint qualifies, with no victim interaction required. Impact is integrity-only and limited (CVSS 5.3; assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), affecting stock levels and downstream report queries rather than confidentiality or availability; publicly available exploit code exists (a Python PoC is published on GitHub), but there is no confirmed active exploitation (CISA KEV) at time of analysis, and no vendor patch reference was identified.
Missing authorization in yshop-crm through 2.1.3 lets any authenticated back-office user approve or reject arbitrary invoices through POST /admin-api/crm/invoice/check, bypassing the intended approval workflow by supplying any invoice id. The CrmInvoiceController check handler carries no @PreAuthorize annotation and the approver-identity checks in CrmInvoiceServiceImpl are commented out, so a low-privileged account with a valid session is sufficient; authentication is still required (CVSS v4.0 AV:N/PR:L; internal assessment CVSS v3.1 5.3 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), so anonymous remote exploitation is not possible. Publicly available exploit code exists (a Python PoC published on GitHub), but there is no indication of confirmed active exploitation (not listed in CISA KEV). Impact is limited to unauthorized modification of the invoice approval state - no data disclosure, privilege escalation beyond the workflow, or code execution has been demonstrated.
Authenticated low-privilege users of jshERP (through version 3.6) can read any tenant settlement account ledger by supplying an arbitrary accountId to the GET /account/findAccountInOutList endpoint, bypassing personal or department-level data scope restrictions. This missing authorization check (CWE-862) discloses bill numbers, counterparties, amounts, and remarks, but remains confined to the same tenant and does not allow writes or privilege escalation. Publicly available exploit code exists, though active exploitation has not been confirmed and the risk is assessed as moderate severity.
Any authenticated low-privilege user of jshERP through 3.6 can read the tenant-wide operation audit log because the LogController endpoints /log/list and /log/info validate that a session exists but never check the caller's role or ownership of the records (CWE-862 missing authorization). A single valid account, including one with minimal privileges, is therefore enough to harvest other users' login names, client IP addresses, and recorded actions over plain HTTP GET requests, with no user interaction and no non-default configuration required. Publicly available exploit code exists (a PoC script published alongside the request that also references message tampering), but the vulnerability is not confirmed as actively exploited and the assessed impact is limited to information disclosure - no integrity or availability effect - giving a CVSS 4.0 base score of 5.3 and an assessed CVSS 3.1 score of 5.3, a low-to-moderate priority disclosure issue rather than an emergency.
Authenticated administrators can enumerate other administrators' network-disk files on MoguBlog through version 6.2 by sending a POST request to /networkDisk/getFileList, which filters results only by status, file type, or filePath and never by the owning admin_uid. The flaw is an insecure direct object reference (CWE-639) that leaks file names and download URLs, giving a low-privilege admin read-only visibility into peers' stored files, which is most impactful in multi-administrator or shared-tenant deployments. It carries a moderated severity rating (CVSS 5.3, assessed separately as CVSS:3.1 5.3 with only confidentiality impact) and publicly available exploit code exists, though no confirmed active exploitation has been reported.
Broken access control in MoguBlog through 6.2 lets any authenticated administrator move or rename another administrator's network-disk files and folders by sending crafted requests to POST /networkDisk/moveFile, batchMoveFile, or edit, because those handlers update database rows without any admin_uid ownership check. Publicly available exploit code exists (a Python PoC that exercises the missing network-disk ownership check), but exploitation is only meaningful in multi-administrator deployments where the attacker holds a valid admin session and knows or guesses the victim's file paths, making this a low-to-moderate priority issue rather than an emergency. CVSS 5.3 reflects integrity-only impact, with no confidentiality or availability loss and no user interaction required.
Missing authorization checks in yshop-crm through version 2.1.3 allow any authenticated back-office user to approve or reject contract receivables records by calling POST /admin-api/crm/contract-receivables/check, because the controller handler carries no @PreAuthorize annotation and the approver role checks inside CrmContractReceivablesServiceImpl.check are commented out in the shipped code. Attackers can approve receivables by id, inflating the associated contract's return_money value and generating forged approval log entries, giving a low-privilege insider or a compromised back-office account the ability to manipulate financial approval state. Publicly available exploit code exists (a proof-of-concept Python script published on GitHub), although there is no confirmation of active exploitation, and the EPSS/KEV signals in the supplied data do not indicate confirmed in-the-wild use; the practical prerequisite is a valid low-privilege authenticated session (PR:L in the assessed CVSS:3.1 vector).
Any authenticated back-office user of yshop-crm (through 2.1.3) can approve or reject customer contracts without holding approver privileges, because the CrmContractController endpoint POST /admin-api/crm/contract/check ships with no @PreAuthorize annotation and its approver-identity checks commented out. Approving a contract silently mutates downstream deal and purchase data, while rejecting one returns goods to stock - an integrity-only impact with no disclosed confidentiality or availability loss. Publicly available exploit code exists (a PoC script in the cve-request-poc repository), but there is no evidence of confirmed active exploitation; the attack still requires a valid low-privilege back-office session.
Authenticated users of TDuck survey form (through version 6.0) can overwrite other tenants' form themes - colours and image URLs - by submitting a victim's predictable, sequential theme id together with their own formKey to the saveFormTheme handler. The flaw is an insecure direct object reference (CWE-639) with no confidentiality or availability impact; the assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, so exploitation requires a valid TDuck account and a form that currently has no theme assigned, which is the state in which the handler is reached and the ownership check is skipped. Publicly available exploit code exists (a Python PoC published by VulnCheck's reporter), but there is no confirmed active exploitation (no CISA KEV listing), making this a low-to-moderate, multi-tenant data-tampering risk rather than an account-takeover or data-disclosure issue.
A container escape in sandboxed.sh through 1.3.0 lets code running inside a container workspace read and modify files on the host filesystem, defeating the isolation the product is designed to provide. The flaw stems from the tool invoking nsenter without the --root flag, so absolute paths resolved by agent-run code land on the host root rather than the container's own filesystem. Exploitation requires the attacker to already execute code inside a sandboxed.sh workspace (low privilege, local), not remote or unauthenticated access, and no public exploit code or confirmed active exploitation has been identified; the effective CVSS 3.1 vector is AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, which materially tempers the headline 9.3 score despite the high confidentiality, integrity, and availability impact.
Remote code execution in NetEase Cloud Music for Windows 3.1.38 and 3.1.39.205426 allows an attacker with an active adversary-in-the-middle position to forge the /pc/upgrade/get upgrade-check response using a publicly known AES key over an unvalidated TLS connection, inject renderer content, and invoke the os.navigateExternal IPC bridge with a file:// URL to execute arbitrary local binaries under the logged-in user. The vendor CVSS 4.0 score is 9.2, and the independent assessment retains high confidentiality, integrity, and availability impact with no privileges or user interaction required, though AC:H reflects the network-position prerequisite; no public exploit identified at time of analysis and no CISA KEV active exploitation is indicated.
Authentication bypass in LibreNMS before 26.9.0 allows unauthenticated remote attackers to gain administrative access when the system is configured for LDAP or Active Directory authorization and the REMOTE_USER server variable is not forwarded by an upstream proxy. The flaw arises because usernames are inserted unescaped into LDAP search filters, and authentication only verifies that a matching entry exists; an attacker can supply a wildcard username via the HTTP Basic Authorization header (PHP_AUTH_USER) to match all users and groups, resulting in admin privileges. Exploitation requires the vulnerable authorization mode to be active and REMOTE_USER to be absent; installations using other auth backends or a correctly configured front-end proxy are not exploitable via this path. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV).
Authentication bypass in ZITADEL's Login V2 UI (versions 3.0.0 through 4.19.1) allows unauthenticated attackers to take over user accounts, including administrators with MFA completed, by forging unsigned session cookies and guessing time-ordered session IDs around a victim's sign-in to trigger token rotation. Exploitation requires the target to run the affected Login V2 UI and the attacker to hit a narrow timing window; no public exploit code is identified at time of analysis. While the CVE carries a CVSS 4.0 score of 9.2, the independent assessment rates it with high attack complexity (CVSS 3.1 AV:N/AC:H/PR:N/UI:N), reflecting the timing prerequisite.
Server-side request forgery in Crawl4AI (unclecode) versions 0.7.0 through 0.9.3 lets unauthenticated, remote API clients force the crawler to fetch internal, private, and cloud-metadata URLs and hand back the parsed head data of those responses. The attack abuses the optional link_preview_config on /crawl requests: an attacker submits a page they control with include_external and include_patterns enabled, and the AsyncUrlSeeder component then follows links pointing at internal services or the cloud instance metadata endpoint. Exploitation requires the non-default link_preview_config feature to be active and the /crawl API to be network-reachable; the CVSS vector (PR:N, UI:N) indicates no authentication or user interaction is needed once those conditions hold. No public exploit code has been identified at time of analysis, and the issue is rated 9.2 under CVSS 4.0 (independent assessment: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N), making this a genuinely high-priority flaw for affected deployments.
Malicious firmware updates can be installed on devices running SWUpdate through 2026.05.1 due to improper validation of X.509 certificates embedded in CMS SignedData, allowing an attacker with a signing key from a sibling intermediate CA under the same trusted root to bypass signature verification. The vulnerability is present in default builds and requires no user interaction or device privileges, but exploitation is limited to environments where the trusted root has multiple intermediate CAs. No public exploit code or active exploitation has been identified at time of analysis.
Unauthenticated SQL injection in phpMyFAQ versions prior to 4.1.9 lets remote attackers read credentials and configuration secrets, modify or delete records, or drop tables via the search parameter of the api/autocomplete endpoint. Exploitation is conditional: the backend MySQL or MariaDB instance must be running in NO_BACKSLASH_ESCAPES mode, because PdoMysql::escape() relies on backslash escaping of single quotes that that SQL mode treats literally; the payload additionally uses a Unicode right single quotation mark (U+2019) that the application normalizes to an ASCII quote after escaping has already been applied, bypassing the filter. This is a genuine high-priority issue (CVSS 4.0 base 9.2, AT:P/AC:H reflecting the non-default SQL-mode prerequisite) rather than a high-CVSS artifact, since an attacker who reaches such a deployment needs no authentication and no user interaction; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the primary limiting factor is whether the target database uses the default SQL mode.
Unauthenticated account takeover in Portal del Hermano (Netherman, portaldelhermano.es) builds earlier than 2026-10-06 exploits the password-recovery endpoints POST /password/create-access and POST /password/email, which lack rate limiting and return distinct error messages acting as oracles for DNI, date of birth, phone number, and last four IBAN digits. An attacker can confirm the DNI, brute-force date of birth and IBAN digits, obtain the phone number via OSINT, and supply an attacker-controlled email to receive the password-reset link, achieving full takeover of any member account across all tenants, including profile data, full IBAN, and fiscal documents. No public exploit identified at time of analysis; disclosed CVSS 9.1 (CVSS 4.0) reflects high impact but high attack complexity (AC:H, PR:N, UI:N per independent assessment).
Account takeover of registered Thirty Bees customers is possible through an authentication bypass in PasswordController::resolveCustomer() affecting versions through 1.7.0. Unauthenticated remote attackers who know a victim's email and operate on a store with guest checkout enabled can place a guest order using that email, retrieve the resulting guest account's secure_key, and submit it as a password-reset token to reset the victim's password because the application does not distinguish guest from registered accounts. No public exploit identified at time of analysis, but the vendor has released an upstream fix commit (66410fd2a7ca9d1121a4b9551f59637ae6e4bcf1).
OTRS fails to immediately invalidate previously issued JWT authentication tokens when an agent or customer user account is deactivated or its password is changed, leaving tokens valid until their normal expiration (approximately 16 hours). An attacker who already possesses a valid token can continue accessing OTRS with the associated privileges, though customer tokens are limited to that account and agent tokens may reach broader ticket, customer, or administrative functions. The flaw provides no way to obtain a token; exploitation requires prior token possession, and the provided CVSS 9.1 (PR:N) overstates ease of attack because it does not account for this prerequisite. No public exploit identified at time of analysis.
OS command injection in Tuleap Enterprise Edition versions 17.0 through 17.5 allows an authenticated, low-privilege user to execute arbitrary commands on the underlying server, delivering a full compromise of confidentiality, integrity, and availability (CVSS 3.1 base 8.8, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Because the assessed vector specifies PR:L, exploitation requires a valid account on the target instance - a registered project or site user is sufficient - and no user interaction is needed once that access is obtained, so unauthenticated attackers cannot trigger it directly. No public exploit code was identified at time of analysis and the CVE is not listed in CISA KEV; no EPSS score was supplied in the source data. Practical risk is therefore concentrated on internet-reachable Tuleap Enterprise Edition instances in the 17.0-17.5 range that allow self-registration or broad account provisioning, since such deployments effectively lower the credential barrier to exploitation.
Unauthenticated attackers can bypass security controls on REST endpoints generated by Quarkus REST Data Panache when a developer uses @MethodProperties to customize an operation without re-declaring class-level security roles, causing the generator to silently drop the security requirement and expose the endpoint. This results in potential unauthorized information disclosure or data modification, with a CVSS 3.1 score of 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) and CWE-425. No public exploit code has been identified at the time of analysis.
Remote unauthenticated attackers can manipulate object attributes through the Apache Allura REST API in versions up to and including 1.21.0, because the API's object-binding logic (CWE-915, mass assignment) fails to whitelist which client-supplied fields may be written. The published CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, giving a base score of 9.1 with high confidentiality and integrity impact and no availability impact, and no user interaction or credentials are required per that vector, though the practical exposure is limited by the small, largely self-hosted population of Allura instances and whether the affected write endpoints are reachable or gated behind authentication in a given deployment. Exploitation does not appear to be widespread: EPSS is only 0.29% (20th percentile), there is no CISA KEV listing, and no public exploit code was identified at time of analysis; the vendor-released fix is Apache Allura 1.22.0.
Stored cross-site scripting in Pimcore through 2026.3.1 lets an authenticated backend user who holds data object edit permission plant an attribute-breaking payload in an ExternalImage class-definition field, and that JavaScript then runs in the admin origin when another user opens the affected object's version preview or version diff view. The injected script stays dormant until a second user navigates to the preview/diff screen, so exploitation is not self-triggering and there is no anonymous or default-configuration remote path; publicly available exploit code exists and a technical write-up plus a VulnCheck advisory are referenced. Impact is confined to the admin backend origin and yields limited confidentiality and integrity effects, so this warrants moderate rather than urgent prioritization and should be scheduled with other backend XSS hardening work.
Privasys ra-tls-clients verifiers before 0.11.0 accept TEE attestation evidence without binding it to an explicitly authorized platform identity, so an unauthenticated remote attacker (CVSS vector PR:N) who can either forge attestation evidence or extract attestation secrets from a separate compromised-but-still-unrevoked Intel SGX/TDX or AMD SEV-SNP platform can present valid measurements from that other machine and impersonate the attested TLS endpoint to the verifier. Exploitation is gated by high attack complexity (AC:H, AT:P) because the attacker must actually control or forge a genuine unrevoked TEE platform, but confidentiality and integrity impact is rated High (assessed CVSS:3.1 8.1; vendor CVSS 4.0 score 9.1), and affected deployments are precisely those running the default policy with an empty platform allow-list. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; the flaw is fixed by ra-tls-clients 0.11.0, which introduces platform allow-listing that fails closed.
TLS certificate validation bypass in NetEase Cloud Music for Windows 3.1.38 and 3.1.39.205426 lets a network-adjacent attacker who already holds a man-in-the-middle position present a rogue CA certificate, decrypt HTTPS traffic, and capture the MUSIC_U session credential for account takeover; in-transit response modification is also possible. The client validates neither the server certificate chain nor the hostname and does not consult the Windows certificate trust store, so no victim authentication or interaction beyond normal app use is required. The reported CVSS 4.0 base score is 9.1, but exploitation is constrained by the positional prerequisite (shared Wi-Fi, rogue AP, ARP spoofing, or compromised router), and no public exploit identified at time of analysis and no CISA KEV entry has been observed.
OAuth1 request replay in Apache Allura through 1.21.0 lets a remote, unauthenticated attacker reuse a previously captured OAuth1-signed request to act with the original requester's authorization, because the platform does not adequately enforce nonce/timestamp single-use. The practical barrier is high rather than trivial: the attacker must first obtain a genuine signed request from a legitimate user - most plausibly through network interception, a man-in-the-middle position, or access to logged or leaked requests - and the replay only yields the scope of that specific captured request rather than arbitrary access, which is why the attack-complexity is assessed as high (AC:H) despite the PR:N vector. No public exploit code and no confirmed active exploitation were identified at time of analysis; EPSS is low at roughly 0.15% (4th percentile), so mass scanning is unlikely, though the vendor has published a fix in Apache Allura 1.22.0.
Open redirect flaw in the OAuth1 callback validation of Apache Allura through 1.21.0 allows unauthenticated remote attackers to redirect users to arbitrary attacker-controlled URLs during the OAuth authorization flow (CWE-601), potentially exposing authorization codes or tokens if a victim completes the flow. Exploitation is not drive-by: per the independent assessment a user must be induced to traverse the attacker-influenced OAuth request (UI:R), which lowers real-world risk below the supplied 9.1 base score; the vendor patched the issue in Allura 1.22.0, no public exploit identified at time of analysis, and EPSS is 0.15% (4th percentile), so this is assessed as a moderate real-world priority.
Authenticated users of Blinko through version 1.8.8 can achieve remote code execution as root by supplying a plugin name containing '../' sequences to the plugin.installPlugin tRPC procedure, which constructs the install path from the unsanitized name and writes downloaded plugin files outside the plugins directory. Because the official Docker image runs as root, an attacker can overwrite a root-owned startup file and gain code execution at the highest privilege level; the endpoint is open to any authenticated account and the referenced sign-in code indicates self-registration may be enabled, potentially letting an unauthenticated outsider obtain the required account. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8), reflecting a genuine high-priority issue rather than a CVSS-inflated paper risk; no confirmed active exploitation is indicated by CISA KEV, though the references include a public repository dedicated to this path-traversal RCE chain that should be treated as potential exploit material.
Authenticated content editors on Grav CMS sites running the Git Sync plugin versions 1.0.2 through 3.4.12 can execute arbitrary OS commands as the web-server account when the plugin's gravuser or gravfull author mode is enabled, by planting shell substitution payloads in their username, full name, or email profile fields that are later interpolated into a git commit --author call and reach PHP exec(). The vulnerability is rated 8.7 (CVSS 4.0) and maps to CWE-78; the assessed vector (CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) confirms that exploitation requires authenticated, low-privileged editor access but no victim interaction, with the additional gating condition that author mode must be explicitly turned on and must not be left at its default posture. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), so it is a credible, prioritizable bug rather than a drop-everything emergency - though any site with untrusted or broadly provisioned editor accounts and author mode enabled should treat it as an immediate command-execution risk.
Local privilege escalation in Samsung's WSM service lets a malicious or compromised process already running on the device trigger a use-after-free and execute arbitrary code with system-level privileges. The flaw affects Samsung mobile firmware builds released before SMR Oct-2026 Release 1; remote network exploitation is not possible because the attacker must first have local code execution able to reach the WSM interface. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV), but the cross-boundary impact (scope change with high confidentiality, integrity and availability impact) makes prompt installation of the October 2026 security maintenance release the priority for any unpatched device.
Code for IBM i (vscode-ibmi) releases before 3.0.1 install and later execute IBM i component programs without verifying their integrity, so an authenticated attacker holding a separate local account on the same IBM i system can modify a component such as GETMBRINFO when it was deployed with permissive *PUBLIC authorities, and the altered program then runs in the context of any user who subsequently connects through the extension. The reported CVSS 4.0 score is 8.9, but the independent assessment rates the issue CVSS 3.1 AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H, reflecting that exploitation requires valid local IBM i credentials, a loosely secured component object, and a victim initiating a connection that triggers the tampered program; no public exploit code or confirmed active exploitation was identified at time of analysis. Version 3.0.1 fixes the flaw, with details in GHSA-rmqv-7c5v-wvjc.
Configuration-validation bypass in Nginx UI (versions 2.0.0-rc.6 through 2.4.0) lets an authenticated low-privilege user write arbitrary nginx configuration directives through the MCP tool nginx_config_add, which persists the file and triggers an nginx reload without ever calling config.ValidateConfigFile - the guard the REST endpoint POST /api/configs does invoke. Because blocked directives such as perl, js_import, load_module and user root can therefore be injected, an attacker on a host with the nginx Perl, njs or Lua module loaded can escalate this into post-authentication remote code execution; on hosts without a scripting module the effect is arbitrary config tampering and reload. The issue is fixed in Nginx UI 2.4.1, and no public exploit code or confirmed active exploitation has been identified at time of analysis.