CVE-2026-100626 is an authorization bypass vulnerability in capgo.app versions up to 12.128.2. It affects the PUT /app/:appId endpoint, allowing authenticated users to supply arbitrary icon storage paths in a private images bucket. This enables them to obtain service-role-signed URLs valid for 7 days, which can be used to read cross-tenant objects such as user avatars, organization logos, and app icons without proper authorization.
GitPython versions before 3.1.62 contain a path traversal vulnerability in the handling of the `path` field from untrusted .gitmodules files during submodule updates. This flaw allows directory creation outside the repository working tree, potentially leading to unauthorized file system modifications. The vulnerability requires an application flow that updates submodules at a non-HEAD commit, which is less common. The issue is fixed in GitPython 3.1.62.
Budibase server versions before 3.45.0 have an authorization bypass vulnerability in the GET /api/applications/:appId/appPackage endpoint. This flaw allows authenticated users to access another tenant's application metadata and source code without proper authorization. Sensitive details exposed include navigation structure, role names, internal screen URLs, JavaScript snippets, and user identifiers.
CVE-2026-100687 is a vulnerability in Budibase Server versions before 3.45.0 where plaintext datasource credentials are exposed to unauthorized actors. This occurs because the server fails to redact sensitive information such as database passwords and API keys before broadcasting external table updates to the Builder collaboration websocket room. Attackers with Builder access can intercept these unredacted credentials during table save or delete operations.
Budibase server versions before 3.45.0 contain an improper privilege management vulnerability in the POST /api/global/groups/:groupId/apps endpoint. This flaw allows builders to bypass per-application authorization checks and assign themselves admin roles in other workspaces by modifying user group role mappings. The vulnerability enables privilege escalation across workspace boundaries.
Budibase server versions before 3.45.0 contain an authorization flaw in the GET /api/chat-links endpoint. This flaw allows users with builder access in one workspace to enumerate chat identity link records across all workspaces within the same tenant. Sensitive information exposed includes user IDs and external chat service identifiers from other workspaces that the attacker should not have access to.
Budibase server versions 3.41.0 up to but not including 3.45.0 contain a critical authentication bypass vulnerability in the OIDC/SSO login path. The flaw allows an attacker who can register at a trusted IdP to claim a pending user invite by asserting the victim's invited email address without proper validation of the invite code or email verification. This enables the attacker to inherit all privileges granted to the invite, including admin rights, leading to full tenant compromise and denial of onboarding to the legitimate invitee.
CVE-2026-100683 is a high-severity SQL injection vulnerability in Budibase server versions before 3.45.0. It arises from improper neutralization of special characters in SQL commands when renaming database columns via the Budibase UI. An attacker with DDL rights on a connected MySQL or MSSQL datasource can exploit this to execute arbitrary SQL statements with the privileges of Budibase's datasource user. This allows unauthorized reads, writes, or destructive operations on the connected database, bypassing Budibase's permission model. The issue is fixed in version 3.45.0.
CVE-2026-100682 is a high-severity vulnerability in Budibase Server versions before 3.45.0. It involves an arbitrary file write issue in the PWA icon upload endpoint, where user-supplied ZIP archives are extracted without proper symlink validation. Attackers with BUILDER role privileges can exploit this by crafting malicious ZIP files to write arbitrary files as root, potentially leading to remote code execution.
Budibase server versions prior to 3.45.0 contain a server-side request forgery (SSRF) vulnerability in the Microsoft Teams webhook endpoint. This flaw allows unauthenticated attackers to submit crafted POST requests with attacker-controlled serviceUrl values, which are persisted and used in subsequent bot replies. Exploitation can lead to the server sending live Microsoft OAuth access tokens to attacker-controlled hosts and enable blind internal network access. The vulnerability has a medium severity with a CVSS 4.0 score of 6.3.
Budibase server versions prior to 3.45.0 contain a vulnerability in the OpenAPI/Swagger import validator that allows authenticated builder users to read arbitrary local files. This occurs because external JSON reference resolution is not disabled, enabling attackers to embed file:// references to exfiltrate sensitive information such as environment variables, JWT secrets, API keys, and database credentials.
The Grav Data Manager plugin (getgrav/grav-plugin-datamanager) versions 1.0.1 through 1.4.4 render stored data entries in the item-detail view (admin/templates/partials/item.html.twig) without escaping, applying Twig's `raw` filter — in some cases after a striptags('<br>') call that PHP's strip_tags() bypasses by preserving allowed tags together with their attributes. An unauthenticated visitor who submits a front-end form whose submissions are saved to user/data can store an HTML payload that executes as JavaScript in the session and origin of an administrator who later opens that entry in the classic admin panel, running with that administrator's privileges and CSRF token. Execution occurs without further interaction for list values (such as checkbox or multi-select fields) and on hover for ordinary text fields. Sites using the Grav 2.0 Admin Next interface are not affected, because it renders the same data through a separate, correctly escaping code path. The issue is fixed in Data Manager 1.4.5.
The Comments plugin (getgrav/grav-plugin-comments) for Grav CMS through version 1.2.10 registers an admin handler that returns comment data as JSON without any authentication check. The handler branches on isAdmin(), which only indicates that the admin service is registered on the current route rather than that the visitor is authenticated, and it echoes the JSON and calls exit() during the plugins stage, before the classic Admin plugin would render its login screen. On a site using the classic Admin plugin with Comments enabled (the default), an unauthenticated remote attacker can request /admin/comments/page:<n> (e.g. page:0.001) and retrieve every comment from the last 7 days, including each commenter's email address and the absolute server filesystem path of the data file. Sites running the Grav 2.0 Admin Next stack (admin2 + api) are not affected via this path. The issue is fixed in 1.2.11, which requires an authenticated user with admin.comments or admin.super and removes the absolute filePath from the response.
Grav is a flat-file CMS. In versions 2.0.19 through 2.0.24 — and in 2.0.0 through 2.0.18 and 1.7.x only where content Twig has been explicitly enabled — page content authored by a user holding only page-write permission is rendered through a Twig sandbox that allowlists get_cookie(), which returns any cookie sent with the current request, including the visitor's session cookie. Because the read occurs server-side via filter_input(INPUT_COOKIE, ...), the HttpOnly, Secure and SameSite attributes offer no protection. Grav then stores the finished post-Twig output in a page-content cache keyed only on page identity and the configuration checksum, with no session, user or request dimension and no bypass for authenticated visitors. A page published by a page-write user can therefore capture the session identifier of the next administrator who views it, after which the cached output serves that identifier to unauthenticated visitors, who can replay the cookie to authenticate as that administrator. Since 2.0.19, security.twig_content.process_enabled defaults to true and Security::applyTwigContentDefault() derives each page's process.twig flag from that gate, so content Twig runs on every page with no frontmatter or operator action. Fixed in 2.0.25; 1.7.x is outside the backport scope.
Grav CMS 2.0.14 through 2.0.24 contains a privilege escalation vulnerability in the group and account blueprints. The access map is gated by a `security@: admin.super` guard that is resolved by the field's exact path, so a submitted flat dot-notation key such as `access.admin.super` (instead of the nested `access[admin][super]`) matches no blueprint rule, survives BlueprintSchema::filterArray() and flattening, and is written by FlexObject::update() via setNestedProperty(), which splits on `.` and reconstructs the nested value. An authenticated backend operator using the flex accounts backend who holds admin.users but not admin.super can therefore grant admin.super to their own account or to a group they belong to and escalate to full super-admin, gaining control over configuration, plugin and theme installation, the file manager, and all accounts. Fixed in 2.0.25, which drops any dotted key whose ancestor path is disabled or marked validate.ignore.
Grav before 2.0.25 ships web server configuration samples whose access-control deny rules are matched case-sensitively. In webserver-configs/web.config (IIS), every deny rule (user_sensitive_folders, user_accounts, user_data, user_error_redirect, user_pages, system, vendor, ignore_folders) sets ignoreCase="false" on its URL Rewrite <match> element, overriding the IIS default of ignoreCase="true"; because these are rewrite matches rather than <requestFiltering> elements, there is no case-insensitive fallback. On IIS running over case-insensitive NTFS, an unauthenticated remote attacker can vary the case of a folder name or file extension (for example GET /user/CONFIG/system.YAML) so that no deny rule matches and the IIS static file handler resolves and returns the underlying file, disclosing sensitive data such as configuration secrets or account password hashes. Whether a bypassed file is actually returned depends on MIME registration: .json is served by default, while .yaml/.yml return HTTP 404.3 on a stock IIS unless a YAML MIME mapping has been added. The same class of gap exists in the bundled webserver-configs/lighttpd.conf, whose user/(config|env), directory, script-extension, root-file and dotfile rules lack the (?i) modifier, though it is lower risk because lighttpd typically runs on case-sensitive filesystems. Deployments served by Apache (.htaccess), nginx, Caddy, or the PHP built-in server are not affected. The issue is fixed in 2.0.25; because the .htaccess installer heal does not touch web.config or lighttpd.conf, operators must re-copy the corrected sample files after upgrading.
Grav 2.0.0 through 2.0.24 contain a Twig content sandbox escape. The `array` filter (and its identical function form) is on the sandbox allowlist but is registered without the needs_is_sandboxed guard that print_r, vardump, json_encode, yaml_encode and string carry, and its implementation calls toArray() — or falls back to an (array) cast — without consulting the sandbox method allowlist. Because the `grav` Twig global is the raw Pimple-based dependency injection container, a user who can author Twig in page content can evaluate `grav|array` to read the container's private $values array, including the un-redacted Config service; a second array cast returns the entire configuration tree, disclosing plugin credentials, SMTP and OAuth secrets, Redis passwords, proxy URLs and the security.* subtree that the sandbox's redaction is meant to hide. Because the payload is stored in page content, the disclosed configuration is rendered to anonymous visitors. Grav 1.7 is not affected as it has no Twig content sandbox. Fixed in Grav 2.0.25.
grav-plugin-login (the Grav CMS Login plugin) versions >= 3.8.7 and < 3.9.7 allow the two-factor authentication challenge to be bypassed for content gated by the authenticated() Twig function or the [authenticated] shortcode. On sites with 2FA enabled, Login::isAuthenticated() checked only the session flag indicating that the password step had succeeded, not the flag indicating that login had completed, so a session sitting at the 2FA code prompt was treated as fully authenticated. An attacker who knows a member's password but cannot answer that member's second factor can therefore read member-only content rendered by the no-argument authenticated() or group authenticated(null, 'group') forms and by [authenticated]; the inverse [guest] shortcode is likewise evaluated too early. Impact is limited to disclosure of that content: the attacker does not obtain a completed session, cannot access pages protected by an access: rule, and cannot act as the user. The authenticated('some.permission') form, which goes through UserObject::authorize(), is not affected. Fixed in grav-plugin-login 3.9.7.
vLLM before 0.29.0 accepts user-controlled stop_token_ids on the OpenAI-compatible POST /v1/completions and POST /v1/chat/completions endpoints but validates only that the values are integers, not that each token id is within the model vocabulary/logits range. When min_tokens > 0, the stop token ids are used as logits indices to suppress stop tokens, so an out-of-range id reaches a CUDA indexing operation (index_put_) and triggers a device-side assertion. An authenticated API user can send a single malformed completion request that returns 500 Internal Server Error and puts EngineCore into a fatal state, causing subsequent requests to fail until the service is restarted (denial of service).
vLLM is an inference and serving engine for large language models. In versions from 0.22.1 through 0.28.0, the operator-supplied model revision pin (--revision / --code-revision) is not propagated to several Hugging Face artifact loads for the FunAudioChat and Tarsier2 architectures: the WhisperFeatureExtractor and speech_tokenizer PreTrainedTokenizerFast loads in vllm/model_executor/models/funaudiochat.py and the Qwen2VLConfig.from_pretrained call used by Tarsier2ProcessingInfo in vllm/model_executor/models/qwen2_vl.py. As a result, deployments pinned to a reviewed revision still resolve these behavior-affecting processor, tokenizer, and config artifacts from the repository's default revision, so a later change to the upstream default branch can alter audio preprocessing, speech tokenizer behavior, or Tarsier2 configuration without any change to the operator's configured pin. This is a supply-chain integrity and reproducibility failure for pinned deployments; it is residual to the earlier fix tracked as GHSA-3ww4-5jv9-j5gm / CVE-2026-47155 and does not constitute remote code execution or a trust_remote_code=False bypass. The issue is fixed in version 0.28.0.