Search: ge.call

A vulnerability in the Linux kernel's USB gadget MIDI function (f_midi) was resolved by initializing work in the f_midi_alloc() function. The issue occurs because work initialization was previously done only in f_midi_bind(), which may not always run, leading to uninitialized work and a warning in __flush_work due to work->func being zero. This flaw was fixed by moving the INIT_WORK call to f_midi_alloc().

A vulnerability in the Linux kernel's BPF subsystem related to preemption handling in the bpf_get_stackid function has been resolved. The issue involves the need to disable preemption during the get_perf_callchain call and while accessing its returned trace entries buffer. This vulnerability affects specific linux-azure kernel versions and has a CVSS score of 7.8, indicating a high impact on confidentiality, integrity, and availability.

A vulnerability in the Linux kernel's drm/amdkfd component allows a user with CAP_CHECKPOINT_RESTORE capability to trigger a kernel NULL pointer dereference and cause a system panic. This occurs because the functions create_queue_cpsch() and create_queue_nocpsch() call a restore_mqd() callback without checking if it is NULL during a CRIU queue restore operation. The issue affects specific Linux kernel versions and is triggered only by a crafted restore payload, not by legitimate CRIU images.

A vulnerability in the Linux kernel's scsi qla2xxx driver involves improper serialization of flash version reads in the reset handler. The reset operation calls get_flash_version() without holding the ha->optrom_mutex, allowing concurrent flash register accesses that can corrupt reads. This issue has been resolved by ensuring the mutex is held during the call, matching the VPD update path.

A vulnerability in the Linux kernel's media CEC core was resolved by fixing a memory leak caused by a missed call to rc_free_device(). This issue arose after a code change removed an implicit call to rc_free_device() but failed to remove a NULL assignment, preventing proper freeing of allocated remote control devices. The leak was detected by kmemleak after device unbinding, such as with dw-hdmi. The fix involves removing the NULL assignment to allow cec_delete_adapter() to free the device correctly.

yshop-crm through 2.1.3 contains a missing authorization vulnerability in the CrmInvoiceController issueInvoice endpoint that allows authenticated back-office users to issue arbitrary invoices. Attackers can call the PUT /admin-api/crm/invoice/issue endpoint without required permissions to modify invoice status, inflate contract invoiced amounts with attacker-chosen values, and trigger invoice emails to arbitrary addresses.

CVE-2026-89906 is a high-severity vulnerability in the Linux kernel affecting the LoongArch architecture's BPF jump offset calculation in tail calls. The flaw stems from using a stale code stride for jump distance calculation, which can cause incorrect branch offsets and potentially lead to kernel soft lockups during extra JIT passes. The issue has been fixed by recalculating the offset directly on the absolute target and adding a guard to prevent false aborts during size estimation. Multiple Linux kernel versions prior to 6.17 are affected.

A use-after-free vulnerability in the Linux kernel's perf subsystem was resolved. The flaw occurs due to a race condition between perf mmap() revival and the last munmap() call, leading to a page-level use-after-free. This can allow local privilege escalation to root by any unprivileged user when kernel.perf_event_paranoid is set to 2. The fix involves reordering reference count updates and serialization to prevent the race condition.

Netcore NR255-V version 1.5.130703 contains a stored cross-site scripting vulnerability in L7 content management pages that use eval() sinks, affecting the call board text and policy group handling components. Attackers can inject persistent script payloads through these pages to have malicious code executed in the context of other users viewing the affected content.

`@zereight/mcp-gitlab` is a Model Context Protocol server for GitLab. Starting in version 0.0.1 and prior to version 2.1.27, when the environment variable `ENABLE_DYNAMIC_API_URL=true` is set, the server reads the `X-GitLab-API-URL` HTTP request header and uses it as the base URL for all outbound GitLab API calls made within that request. The server validates that the value is a well-formed URL (`new URL(dynamicApiUrl)`) but applies no allowlist or hostname restriction. The server then attaches the victim's `Private-Token` to every outbound fetch that uses the redirected URL. Any caller who can reach the HTTP transport can set `X-GitLab-API-URL` to an attacker-controlled host. The next GitLab API call the server makes delivers the victim's token to that host. Version 2.1.27 contains a patch.

mcp-searxng is a Model Context Protocol server that gives AI assistants web search and URL-reading capabilities through SearXNG. Prior to 1.2.0, the web_url_read URL policy in src/url-reader.ts can be bypassed while MCP_HTTP_HARDEN is enabled and MCP_HTTP_ALLOW_PRIVATE_URLS is not enabled because redirect targets are not revalidated, 0.0.0.0 is not classified as an internal address, and IPv4-mapped IPv6 literals canonicalized to hexadecimal form are not recognized. These inputs allow an attacker-influenced tool call to make the MCP server fetch loopback or internal HTTP resources and return content from local services, private APIs, service-mesh endpoints, or cloud metadata endpoints. The separate hostname-to-private-address case addressed by the earlier partial fix is not part of these residual bypasses. This issue is fixed in version 1.2.0.

The Issabel Framework, the web framework supporting Issabel PBX software, before commit b97dbaf contains a hard-coded HS256 JWT signing key in the pbxapi index.php file that is identical across every installation, allowing unauthenticated remote attackers to forge valid bearer tokens. Attackers can use the forged token to call the manager originate endpoint with the System application parameter, causing Asterisk to execute arbitrary OS commands as the Asterisk user. Exploitation evidence was first observed by the Shadowserver Foundation on 2026-09-09.

MCP Memory Keeper is an MCP server for persistent context management in AI coding assistants. Prior to 0.13.0, context_import in src/index.ts passes the caller-controlled filePath directly to fs.readFileSync without restricting the path to an export directory. An MCP client, including an LLM agent induced to call the tool, can use ../ traversal or an absolute path to target any file readable by the server process. A valid JSON file is parsed and imported into the caller's session, allowing its full contents to be retrieved through context_get or context_export, while JSON.parse errors for non-JSON files can return leading file bytes in a SyntaxError message. The two disclosure modes can expose other exported sessions, JSON credentials or service-account files, environment files, and portions of SSH keys or other local files. This issue is fixed in version 0.13.0.

CVE-2026-79699 is a vulnerability in the containers/storage library used by Red Hat Ansible Automation Platform 2. It involves improper link resolution before file access, where a crafted tar archive with a malicious whiteout header can cause the extraction destination directory to be replaced with an arbitrary file. This flaw affects external applications that directly call the containers/storage library API. No direct impact on Red Hat container tools has been identified. The vulnerability has a medium severity rating with a CVSS score of 4.4. Currently, no mitigation or patch meeting Red Hat's criteria is available.

Payload Plugins is a collection of plugins designed to enhance Payload CMS. In 0.7.0, @jhb.software/payload-alt-text-plugin exposes POST /api/alt-text-plugin/generate and POST /api/alt-text-plugin/bulk with a default guard that accepts any authenticated user, while alt-text/src/endpoints/generateAltText.ts and alt-text/src/endpoints/bulkGenerateAltTexts.ts call req.payload.findByID and req.payload.update without overrideAccess: false. Payload therefore defaults overrideAccess to true and skips the target collection's read and update access functions. An authenticated low-privilege user can supply id, collection, locale, and update values to read arbitrary protected upload documents and overwrite their alt and keywords fields, even when the collection permits those operations only to administrators. A control Local API call with overrideAccess: false is denied, confirming that the plugin endpoint bypasses otherwise effective collection rules. This vulnerability is fixed in 0.8.0.

### Summary Once a user has TOTP enabled, the API still hands back the raw shared secret to anyone holding that account's access token. Reading it doesn't ask for the password, even though disabling TOTP does. So a stolen token, an XSS, or a browser left open is enough to copy the second factor into your own authenticator and keep generating valid codes indefinitely. ### Details `GET /api/v1/user/settings/totp` returns the full TOTP object, including the secret field and the otpauth:// provisioning URL. `GET /api/v1/user/settings/totp/qrcode` renders the same secret as a QR image. Neither requires re-authentication, the access token alone is enough. This is inconsistent with the rest of the flow: `POST /api/v1/user/settings/totp/disable` calls CheckUserPassword before it will turn TOTP off. So the destructive action is gated behind the password, but reading out the secret that backs the second factor isn't. There's also no reason for the secret to be readable at all once enrollment is finished, the client only needs it during setup. The fix is to stop returning secret/url/the QR code once enabled is true (only expose them during the enrollment window). Requiring the password on the read, like disable already does, would also be reasonable. ### PoC The attacker needs the victim's access token, from an XSS, a leaked/stolen token, or an unlocked session. TOTP must already be enabled on the account. 1. With the victim's bearer token, call: ``` GET /api/v1/user/settings/totp Authorization: Bearer <victim_token> ``` The response contains the shared secret and the otpauth:// URL: ``` {"secret": "<base32 secret>", "enabled": true, "url": "otpauth://totp/..."} ``` 2. Paste that secret (or scan `/api/v1/user/settings/totp/qrcode`) into any authenticator app. 3. It now produces the same 6-digit codes as the victim's device. Nothing is logged and the victim gets no notification. ### Impact This defeats the purpose of the second factor. 2FA is supposed to survive exactly this situation, a compromised password or a hijacked session, but a single read of the account's own settings hands over the shared secret with no step-up check and no trace. Combined with a known or later-recovered password, it's a durable account takeover that TOTP was meant to prevent.

### Summary A link-share token, the credential you hand out to let someone view a shared project, can call the v2 user-search endpoints, which it was never meant to reach. The v1 versions of the same endpoints correctly reject link-share tokens; the v2 versions don't. As a result, anyone with a share link can list every member of the shared project (and its parent projects), and can test whether any username exists anywhere on the instance. ### Details Two endpoints are affected: `GET /api/v2/projects/{id}/users/search` only checks project.CanRead, which a link share satisfies on its own project. With no parameter it returns the full user list, walking up the parent-project chain. `GET /api/v2/users?q=<name>` is a global search. It needs a query term, but any term works as an existence oracle: a hit confirms the username exists somewhere on the instance and returns the display name. Emails are correctly stripped from these responses, so the exposure is limited to identities (usernames and display names), but that's still an instance-wide directory that a share-link holder should never see. The fix is to resolve the caller with GetFromAuth in both handlers, so link-share tokens are rejected the same way v1 already rejects them. ### PoC 1. Get a link-share token. With any account that owns a project, create a read-only link share and note the hash, then exchange it: ``` POST /api/v1/shares/<hash>/auth {"password":""} ``` The response contains a token, a link-share JWT. 2. Confirm v1 blocks it (the fixed behavior). With that token: ``` GET /api/v1/projects/<id>/projectusers Authorization: Bearer <link_share_token> ``` → rejected: the token isn't a user token. 3. Now the vulnerable v2 endpoints, same token: ``` GET /api/v2/projects/<id>/users/search Authorization: Bearer <link_share_token> ``` → 200, full list of everyone with access to the project and its parents (id, username, name). ``` GET /api/v2/users?q=admin Authorization: Bearer <link_share_token> ``` → 200, a non-empty result confirms the username exists on the instance. Iterate q over a wordlist to enumerate accounts. ### Impact Information disclosure. A link share is a low-trust credential meant to expose one project's contents; here it also exposes the membership of that project's parents and lets the holder probe for any username across the whole instance. Since share links are often forwarded or semi-public, this hands an untrusted recipient a map of internal users and a username-validation oracle useful for phishing and credential stuffing. No account is required beyond possessing a share link. Emails are not exposed.

Contentful MCP Server is a Model Context Protocol server for the Contentful Management API. Prior to @contentful/mcp-server 1.7.19 and @contentful/mcp-tools 0.4.5, export_space and import_space in packages/mcp-tools/src/tools/jobs/space-to-space-migration/exportSpace.ts and packages/mcp-tools/src/tools/jobs/space-to-space-migration/importSpace.ts expose host, proxy, rawProxy, and insecure network options to LLM-controlled tool arguments and combine those options with the server's CONTENTFUL_MANAGEMENT_TOKEN. After space_to_space_migration_handler enables the migration tools, a direct MCP call or prompt injection through attacker-controlled Contentful content can redirect Contentful Management API requests and their Authorization header to an attacker-controlled host or proxy. The regular tools that use createToolClient are unaffected because those tools pin the host from server configuration. Exposure of the personal access token permits persistent out-of-band access to every Contentful space within the token's scope. This issue is fixed in @contentful/mcp-server 1.7.19 and @contentful/mcp-tools 0.4.5.

PraisonAI is a multi-agent teams system. From 1.5.0 until 1.7.2, MCPServer.startHttp() in src/praisonai-ts/src/mcp/server.ts binds without a host restriction and forwards every HTTP POST request to handleRequest() without authentication or authorization. Any network client that can reach the port can call tools/list, tools/call, resources/read, or prompts/get, causing registered handlers to run with server-side credentials and process privileges or disclose registered data. An initial remediation was released in version 1.7.2.