Base de CVEs

IBM Power Systems Firmware FW1120.00, FW1110.00 through FW1110.30, FW1060.00 through FW1060.80, and FW950.00 through FW950.H2 is affected by a vulnerability in access controls over privileged system configuration operations on the FSP. An attacker with authenticated administrator-level access to the FSP can place the managed system into a non-production operational mode, allowing certain system components to be disabled. This condition persists across FSP resets and requires explicit operator intervention — clearing the affected configuration — to restore normal operation. Successful exploitation results in an availability impact to the managed system.

Grav Flex Objects Plugin allows you to build custom collections of objects. Prior to 1.4.3, the Grav Flex Objects Admin Next API requireFlexPermission() method in classes/Api/FlexApiController.php returns without denying access when a directory blueprint omits config.admin.permissions. An authenticated account with only api.access can use the index, show, create, update, delete, export, and media handlers for a permission-less directory even though the core admin.flex-object. authorization fallback would deny the same actions. This issue is fixed in version 1.4.3.

phpMyFAQ before 4.1.7 fails to apply parent FAQ visibility checks before returning child resources including comments and attachments. Unauthenticated attackers can retrieve restricted comment text, commenter email addresses, and attachment filenames for FAQ records they cannot directly access by querying the comments and attachments API endpoints.

phpMyFAQ before 4.1.7 fails to properly enforce CONFIGURATION_EDIT permission on admin API read endpoints for LDAP, Elasticsearch, OpenSearch, and dashboard configuration, allowing any authenticated user to access sensitive administrative data. Attackers can retrieve LDAP server topology, bind account names, search bases, index statistics, and site analytics by calling these endpoints with a valid session.

phpMyFAQ versions before v4.1.6 fail to validate the security.enableRegistration setting in API endpoints, allowing attackers to create user accounts when registration is disabled. Attackers can bypass the registration restriction by submitting requests to POST /api/register or POST /api/v3.1/register endpoints, which do not check the configuration flag enforced by the HTML registration page.

Unauthenticated Broken Access Control in Taxi Booking Manager for WooCommerce < 2.0.8 versions.

The TrueBooker WordPress plugin before 1.2.7 does not have proper authorisation checks in one of its AJAX actions, allowing unauthenticated users to delete arbitrary appointment records along with their associated booking items and payment records.

The TrueBooker WordPress plugin before 1.2.7 does not have proper authorisation checks in one of its AJAX actions, allowing unauthenticated users to change the status of arbitrary appointments, as well as to trigger notification emails to the affected customers.

Missing Authorization vulnerability in Kings Plugins B2BKing allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects B2BKing: from n/a through 5.2.30.

The Zephyr kernel validates the k_thread_join() and k_thread_abort() system calls (declared __syscall in include/zephyr/kernel.h) through thread_obj_validate() in kernel/thread.c. Its default switch branch is the access-denied path, taken when k_object_validate() returns -EPERM (the calling user thread was never granted access to the target thread object) or -EBADF (the supplied pointer is not a registered kernel object of the right type). That branch invoked K_OOPS(K_SYSCALL_VERIFY_MSG(ret, "access denied")), but K_SYSCALL_VERIFY_MSG treats a true expression as success; the non-zero error code ret therefore read as "verified OK", the kernel oops was never raised, and control fell through to CODE_UNREACHABLE. Because k_thread_join() and k_thread_abort() are system calls, an unprivileged user-mode thread (under CONFIG_USERSPACE) can reach this denial path directly by calling either syscall on a thread object it does not own. Instead of the offending thread being cleanly terminated, execution reaches __builtin_unreachable() while running in supervisor mode inside the syscall handler. On Clang builds CODE_UNREACHABLE emits an illegal-instruction trap, so a user thread can deterministically crash the kernel — a locally triggerable denial of service that escapes the userspace sandbox. On GCC builds the path is undefined behavior: the compiler may drop the return-value handling for thread_obj_validate(), so it can return an undefined bool; if that is false, the caller proceeds into the real k_thread_join()/k_thread_abort() implementation for a thread the user was never authorized to access, an access-control bypass. The fix changes the verification expression to ret == 0, so a denied (non-zero) result now correctly raises K_OOPS and terminates the offending caller.

Pydio Cells 5.0.0 through 5.0.2 returns share-link details to any authenticated user. The REST handler for GET /a/share/link/{Uuid} in idm/share/rest/handler.go reads the workspace UUID from the path, calls LinkById, and writes the result with no authorization step, whereas the sibling handler for GET /a/share/cell/{Uuid} loads the workspace and requires MatchPolicies with ResourcePolicyAction_READ, returning a not-found error so that existence is not disclosed. Nothing compensates further down: GetLinkWorkspace reaches GetOrCreateWorkspace, which issues SearchWorkspace with a query carrying no ResourcePolicyQuery, and PrepareResourcePolicyQuery returns the query unmodified when that field is nil, so the workspace service applies no policy filter. The workspace UUID is not secret, because the unauthenticated public page served for a share link embeds it as START_REPOSITORY. Any account holding a standard user role can therefore submit the UUID and receive the link hash and URL, the owner's user identifier, the hidden share user login, the permission set, the download limit and count, the target users, the expiry, and the password-required flag, while a direct read of the shared node from the same account is refused.

Lemur manages TLS certificate creation. Prior to 1.9.3, CertificateExport placed its CertificatePermission ownership check inside the plugin.requires_key branch for POST /api/1/certificates//export. A plugin declaring requires_key false bypassed that check, and the handler still passed cert.private_key as an argument and recorded a key_view audit event. The bundled JavaTruststoreExportPlugin ignored the key, so the immediate exposure was limited to public certificate material and misleading audit entries, but a future plugin could have consumed the supplied key. The fix passes no private key to plugins that do not require one and confines ownership checks and key_view logging to actual private-key exports. This issue is fixed in version 1.9.3.

Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/authorities with type=subca did not require AuthorityPermission on the parent authority when ADMIN_ONLY_AUTHORITY_CREATION was false. AssociatedAuthoritySchema resolved the caller-supplied parent and passed it through authority creation to cryptography-issuer, which used the parent authority_certificate.private_key to sign a new intermediate. Any authenticated non-read-only user in that supported configuration could chain a sub-CA to an internal root for which the user held no role. The resulting intermediate could issue trusted certificates and its private key could be used outside Lemur, bypassing normal issuance controls. The fix checks AuthorityPermission on every supplied parent before invoking the issuer. This issue is fixed in version 1.9.3.