| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Kimai is an open-source time tracking application. Prior to 2.58.0, ExportController::createExportTemplate() and ExportController::editExportTemplate() inherit only the class-level create_export permission, which ROLE_TEAMLEAD receives by default, and omit the create_export_template permission required by the API routes and user interface. A teamlead can directly access the export template creation and editing web routes to create or modify global ExportTemplate records marked available to all users, altering export columns, renderer, format, and output used by other users and administrators. This issue is fixed in version 2.58.0. |
| Kimai is an open-source time tracking application. Prior to 2.58.0, POST /api/teams/{id}/members/{userId} and POST /api/teams/{id}/activities/{activityId} verify that a teamlead may edit the Team but do not verify access_user for the referenced User or view access for the referenced Activity. A teamlead can add users or activities outside the teamlead's manageable scope to an editable team, bypassing the narrower choices enforced by TeamEditForm and UserRepository::getQueryBuilderForFormType(). The resulting relationships can be trusted by RolePermissionManager::checkTeamAccessActivity() and other team-based authorization, visibility, reporting, and workflow logic. This issue is fixed in version 2.58.0. |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: purge outqueue on stale COOKIE-ECHO handling
sctp_stream_update() is only invoked when the association is moved into
COOKIE_WAIT during association setup/reconfiguration. In this path, the
outbound stream scheduler state (stream->out_curr) is expected to be
clean, since no user data should have been transmitted yet unless the
state machine has already partially progressed.
However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a
Stale Cookie ERROR is received, the association is rolled back from
COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already
have been queued and even bundled with the COOKIE-ECHO chunk.
During the rollback, sctp_stream_update() frees the old stream table
and installs a new one, but it does not invalidate stream->out_curr.
As a result, out_curr may still point to a freed sctp_stream_out
entry from the previous stream state.
Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on
stream->out_curr->ext, which can lead to use-after-free once the old
stream state has been released via sctp_stream_free().
This results in crashes such as (reported by Yuqi):
BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140
Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312
CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted
7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full)
sctp_sched_fcfs_dequeue+0x13a/0x140
sctp_outq_flush+0x1603/0x33e0
sctp_do_sm+0x31c9/0x5d30
sctp_assoc_bh_rcv+0x392/0x6f0
sctp_inq_push+0x1db/0x270
sctp_rcv+0x138d/0x3c10
Fix this by fully purging the association outqueue when handling the
Stale Cookie case. This ensures all pending transmit and retransmit
state is dropped, and any scheduler cached pointers are invalidated,
making it safe to rebuild stream state during COOKIE_WAIT restart.
Updating only stream->out_curr would be insufficient, since queued
and retransmittable data would still reference the old stream state and
trigger later use-after-free in dequeue paths. |
| When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0. |
| A security vulnerability has been detected in Portabilis i-Educar up to 2.10. The impacted element is an unknown function of the file educar_historico_escolar_lst.php. Such manipulation of the argument ref_cod_aluno leads to sql injection. The attack can be executed remotely. The exploit has been disclosed publicly and may be used. Upgrading to version 2.12 is sufficient to resolve this issue. It is advisable to upgrade the affected component. The vendor confirms, that "[t]he reported attack vector was tested against the corrected code, and the previously described SQL Injection behavior could no longer be reproduced". |
| A flaw in libcurl's handling of HTTP/2 Server Push streams, when the parent
handle is set to share connections with other handles, can lead to
use-after-free in the cleanup process. |
| 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. |
| Pimcore is an Open Source Data & Experience Management Platform. Prior to 2026.1.5, an authenticated user with the objects permission can submit a malicious ClassDefinition UID because the name and ID validation expressions in models/DataObject/ClassDefinition.php validate only the beginning of each value. When a data object of that class containing a Block field is loaded, Block::load in models/DataObject/ClassDefinition/Data/Block.php incorporates the stored class ID into an unquoted object table identifier, allowing the UID to supply SQL syntax. The resulting query can read or modify arbitrary Pimcore database tables, including disclosure of password hashes, and the flaw represents an incomplete validation hardening because earlier work added a start anchor without enforcing the end of the identifier. This issue is fixed in version 2026.1.5. |
| 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. |
| Casdoor through 4.4.0 fails to properly mask the instance-wide built-in certificate private key in /api/get-certs and /api/get-cert endpoints, allowing organization administrators to retrieve it. Attackers can use the exposed private key to forge JWT tokens for any user in any organization, including global administrators. |
| 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. |
| 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 4.6.58, praisonai.jobs.server.create_app mounts praisonai.jobs.router.create_router under /api/v1/runs without authentication or per-job authorization. Network clients can submit attacker-controlled prompts and agent configuration, list and read jobs, stream results, and cancel or delete other jobs, exposing service credentials and connected tool capabilities to unauthorized agent execution. This vulnerability is fixed in 4.6.58. |
| Alchemy is an open source content management system engine written in Ruby on Rails. Prior to 7.4.15, 8.0.15, 8.1.14, and 8.2.6, the unauthenticated GET /api/pages/nested endpoint implemented by Api::PagesController#nested in app/controllers/alchemy/api/pages_controller.rb returns an unfiltered page tree because it performs no authorization and does not scope descendants by the caller's ability. Anonymous callers can retrieve restricted and unpublished page metadata that the sibling show action denies. When elements=true is supplied, PageTreeSerializer also returns element and ingredient content from restricted pages because PageTreePreloader and the serializer do not apply an ability check to those records. This issue is fixed in versions 7.4.15, 8.0.15, 8.1.14, and 8.2.6. |
| 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.15 and 7.0.47, HasMany and MorphMany handling through attachManyRelation during CRUD create and update operations accepts submitted child primary keys without consistently restricting updates to records belonging to the current parent or permitted by the developer-defined relation scope. An authenticated low-privilege administrator who can edit a parent form exposing an affected multiple-relation field can cause unrelated child records to be reassigned, detached, nulled, or deleted across ownership or tenant boundaries. Exploitation requires related records that should not be attachable or removable by that administrator and the absence of additional application-level authorization around submitted relation values. This issue is distinct from earlier direct main-entity CRUD scoping fixes because it affects secondary models modified by relationship-saving logic. This issue is fixed in versions 6.8.15 and 7.0.47. |
| SPIP before version 4.4.18 contains a missing authorization vulnerability in sensitive actions under ecrire/action/ that allows unauthenticated attackers to invoke privileged actions by supplying only a valid CSRF nonce without any server-side permission check. Attackers can bypass template-level authorization guards through direct HTTP requests to invoke actions such as editer_auteur, enabling arbitrary account password rewrites including administrator accounts and resulting in full account takeover. |
| The Zephyr SDIO subsystem function sdio_io_rw_extended_helper() in subsys/sd/sdio.c finishes transfers with a byte-I/O loop that uses size = MIN(remaining, func->cis.max_blk_size) as the per-iteration step. The value func->cis.max_blk_size is decoded directly from the SDIO card's CIS FUNCE tuple in sdio_decode_cis() and is not validated. When a card reports a maximum block size of zero, size is always 0, remaining never decreases, and the loop spins forever.
The loop is reached from the public SDIO client API used by drivers, including sdio_read_fifo(), sdio_write_fifo(), and the incrementing register read/write helpers, each of which enters the loop while holding the per-card mutex func->card->lock. A card advertising max_blk_size == 0 therefore hangs the calling thread permanently on its first non-block-aligned transfer and never releases the mutex, denying service to the SDIO peripheral (and any subsystem such as Wi-Fi that depends on it) until the device is reset.
The malicious value must come from the SDIO card itself, so the defect is exploitable where a removable SDIO/combo card slot lets an attacker insert a crafted or malfunctioning card (a physical attack vector); on boards with a soldered SDIO peripheral it is not attacker-influenceable. There is no memory-safety, confidentiality, or integrity impact — only a permanent availability loss. The fix returns -EIO when func->cis.max_blk_size is zero, before the loop is entered. |
| Pimcore is an Open Source Data & Experience Management Platform. Prior to 11.5.19, 12.3.10, and 2026.1.6, an authenticated user with reports_config permission can place attacker-controlled SQL fragments in the sql, from, where, and groupby fields of a Custom Reports configuration processed by bundles/CustomReportsBundle/src/Tool/Adapter/Sql.php. The buildQueryString() method concatenates these values into a database query, while a blacklist omits dangerous constructs such as additional data-manipulation statements, comments, subqueries, and multiple statements. The getData() method also previously interpolated offset and limit values into a LIMIT clause without integer casting. Executing the configured report reaches fetchAllAssociative() with the constructed query and can disclose, modify, or delete arbitrary database data. This issue is fixed in versions 11.5.19, 12.3.10, and 2026.1.6. |
| 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. |
| A flaw was found in ansible-core. The ansible-galaxy role install command processes dependency specifications from a role's meta/requirements.yml file. Due to improper neutralization of argument delimiters, a malicious role author can inject arbitrary git configuration flags through the src field. This allows arbitrary code execution on the machine of a user who installs the role via ansible-galaxy role install. |
