PraisonAI is a multi-agent teams system. From 1.2.3 until 1.7.2, CommandValidator in src/praisonai-ts/src/cli/features/sandbox-executor.ts validates only the first whitespace-delimited executable against allowedCommands, then SandboxExecutor passes the complete command string to sh -c. A command beginning with an allowed executable can append a non-allowlisted command through shell metacharacters, causing arbitrary commands to run with the PraisonAI process privileges. This issue is fixed in version 1.7.2.
PraisonAI is a multi-agent teams system. From 1.4.0 until 1.7.2, createAgentLoop() in src/praisonai-ts/src/ai/agent-loop.ts passes executable tools to generateText() before invoking the onToolCall approval callback. Because the wrapped AI SDK executes tool handlers during generation, a callback that returns false records tool_rejected only after the denied tool has already produced side effects and populated toolResults. Applications using onToolCall as a human or policy approval boundary can therefore execute rejected file, command, API, or data-modifying operations. This issue is fixed in version 1.7.2.
In affected versions of Octopus Server, users with certain scoped permission sets could execute arbitrary scripts on a worker (including the Octopus Server built-in worker). Incorrect permission validation during script execution would allow the script to execute without the user possessing the required authorisation.
CVE-2026-19816 is a high-severity vulnerability in PackageKit when used with the dnf5 backend. The flaw allows an unprivileged local user to bypass authorization checks and perform an actual package uninstall by exploiting incorrect handling of the SIMULATE (dry-run) flag. This occurs because the RepoRemove handler's guard condition is flawed, causing it to always execute the real transaction instead of simulating it. The issue affects PackageKit version 1.3.4.
backpack/crud provides Create, Read, Update & Delete (CRUD) functions for Backpack, a collection of Laravel packages that help users build custom administration panels. From 6.0.0 until 6.8.14 and 7.0.38, the Update, Delete, and Reorder operations resolve records from the unscoped model query instead of the query configured through addClause() or addBaseClause(). An authenticated user who knows or guesses an out-of-scope record primary key can therefore modify, delete, or reorder records hidden by tenant, ownership, or other row-level access-control scopes. Applications that do not rely on CRUD query clauses for authorization are not affected by this specific bypass. The fix routes all three write operations through getModelWithCrudPanelQuery(), matching the scoped list and read behavior. This issue is fixed in versions 6.8.14 and 7.0.38.
SpiceDB is an open source database system for creating and managing security-critical application permissions. From 1.34.0 until 1.54.0, SpiceDB can return PERMISSIONSHIP_HAS_PERMISSION instead of PERMISSIONSHIP_CONDITIONAL_PERMISSION or PERMISSIONSHIP_NO_PERMISSION because checkRequestToKey() and checkRequestToKeyWithCanonical() in internal/dispatch/keys/computed.go omit CheckHints when constructing dispatch Check cache keys. The incorrect result requires a permission combining relations with intersection or exclusion, a subject reachable through caveated and non-caveated branches, LookupResources with a context parameter running concurrently with CheckPermission or CheckBulkPermissions for the same resource and subject, and an enabled dispatch result cache. Under these conditions, a result computed for one hint set can poison the cache entry used by a semantically different authorization check, allowing permission without satisfying the caveat. This issue is fixed in version 1.54.0.
PraisonAI is a multi-agent teams system. Prior to 4.6.59, the CODE_TOOLS wrappers keep _workspace_root as None and pass workspace=None to read_file, search_replace, and apply_diff helpers that enforce path containment only for a truthy workspace. An application that exposes code_read_file, code_search_replace, or code_apply_diff before set_workspace can therefore let prompt-influenced calls read and modify files outside the intended project directory, while explicitly configured workspaces remain effective. This vulnerability is fixed in 4.6.59.
PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.59 and praisonaiagents 1.6.59, the unauthenticated POST /api/v1/runs Jobs API accepts attacker-controlled agent_yaml, and the approve field can mark execute_command as YAML-approved before @require_approval checks critical tools. This chain allows a remote caller to cause a configured language model agent to invoke arbitrary operating-system commands without credentials or operator interaction. This vulnerability is fixed in praisonai 4.6.59 and praisonaiagents 1.6.59 as fixed versions.
Description
`SimpleACLAuthorizer` evaluated the user-level command set by returning early when `nimbus.users` was empty,
before `nimbus.groups` was considered. An operator who restricted cluster access by group alone, leaving
`nimbus.users` unset, therefore received no restriction at all: every authenticated principal was permitted
every user-level operation, including `submitTopology`, `beginFileUpload` and `getNimbusConf`.
`docs/SECURITY.md` presents `nimbus.groups` as a supported way to lock down a cluster, so a deployment
following the documentation could believe it was restricted while it was not. The failure is silent; nothing
in the logs or the configuration indicates that the group list is being ignored.
Both lists left empty continues to mean that no restriction is configured, which is the shipped default and
is unchanged.
Mitigation
Upgrade to 3.1.0, where `nimbus.groups` is evaluated whether or not `nimbus.users` is set.
Users who cannot upgrade immediately should additionally populate `nimbus.users` with the intended
principals, since a non-empty user list causes the group list to be evaluated on affected versions.
Operators should review Nimbus access logs for operations by principals outside the intended groups.
Note that after upgrading, a cluster configured with `nimbus.groups` alone becomes restrictive for the first
time. This includes `NimbusClient`, which calls `getLeader` on every connection, so clients outside the
configured groups will begin to be refused.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.
Description
Nimbus validated `topology.blobstore.map` against the calling subject at submission time only. The rebalance
operation accepts configuration overrides and stripped a small set of keys from them, but never re-ran that
validation, so a caller authorised to rebalance a topology could introduce a blobstore map entry naming a
blob whose ACL does not grant them access. Supervisors localise whatever key the map names, placing the
blob's contents into the topology's working directory.
The same advisory covers `listBlobs`, which performed no authorization check and passed no subject, unlike
the neighbouring `getBlobMeta` and `beginBlobDownload` operations. It therefore returned every key in the
blobstore to any caller able to reach the Nimbus Thrift port, which provides the key names that make the
above practical. On its own the disclosure is metadata only.
Mitigation
Upgrade to 3.1.0, where rebalance configuration overrides are validated exactly as submission-time
configuration is, against the rebalancing caller, and where `listBlobs` applies the configured
authorization.
Users who cannot upgrade immediately should restrict rebalance rights to trusted principals, keeping in mind
that membership of a topology's `topology.users` or `topology.groups` confers them.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.
Incorrect Authorization vulnerability in Apache Syncope.
Delegated administration security checks are based on Realm hierarchy and enforced via prefix matches.
Due to incorrect implementation, two sibling Realms whose names begin with the same string cannot be correctly distinguished, resulting in incorrect authorization.
This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2.
Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue.
Incorrect Authorization vulnerability in Apache Syncope.
Delegated administration security checks performed by Reconciliation service's pull and push, being incomplete, could accept calls by administrator not provided with adequate entitlements.
This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2.
Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue.
Incorrect Authorization vulnerability in Apache Syncope.
Any search requests are transformed into SQL, Neo4J or Elasticsearch / Opensearch queries, depending on the actual deployment configuration.
An important component of such transformation is the Realms filter, which ensures that the search results are matching the requester's permissions.
For non-recursive search requests it is possible that such Realms filter is rendered as empty, thus voiding any restriction on requester privileges.
This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2.
Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue.
Incorrect Authorization vulnerability in Apache Syncope.
An administrator with adequate entitlements in a given Realm may be able to read via REST the full Connector configuration, confidential properties included, scoped in another Realm and thus be able to effectively duplicate such Connector instance into the Realm they have administration rights for.
This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2.
Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue.
Incorrect Authorization vulnerability in Apache Syncope.
An administrator with ClientApp's update entitlement is unable to perform the related operation, while ClientApp's create entitlement is checked both for create and update operations on ClientApp.
This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2.
Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue.
A role-based access control issue was identified in the administrative expression evaluation functionality. This could allow users with certain administrative roles to access expression testing capabilities beyond their intended permissions.
Incorrect Authorization vulnerability in Apache Doris allows an authenticated user to bypass privilege checks and access data they are not authorized to read, resulting in unauthorized disclosure of information.
This issue affects Apache Doris: from 2.0.0 through 2.1.*, from 3.0.0 through 3.0.*, from 4.0.0 before 4.0.8, and from 4.1.0 before 4.1.4.
Users are recommended to upgrade to a fixed release (4.0.8 or 4.1.4), which fixes the issue.
Incorrect Authorization vulnerability in Apache Doris allows an authenticated user to bypass privilege checks and access or modify data they are not authorized to.
This issue affects Apache Doris: from 3.1.0 through 3.1.*, from 4.0.0 through 4.0.7, and from 4.1.0 through 4.1.3.
Users are recommended to upgrade to a fixed release (4.0.8 or 4.1.4), which fixes the issue.
The application's role-authorization lookup defaults to granting access when a request handler's name is not present in its table of role requirements, rather than defaulting to deny. Any request handler that is not explicitly registered in this table is reachable by any authenticated user regardless of their assigned role, and any newly added handler is fail-open by default until explicitly added to the table.
OpenStack Keystone versions prior to 29.0.3 contain an authorization flaw affecting tokens obtained via delegated authentication methods. These tokens can improperly create, modify, or delete credentials through the /v3/credentials API. EC2-derived tokens can also read sensitive credential blobs, exposing secrets such as TOTP MFA seeds. Additionally, the PATCH /v3/credentials endpoint does not validate the post-update project_id, allowing unauthorized project assignment of credentials. All Keystone deployments using delegated authentication are impacted.