1Panel Dev
Monthly
Missing authorization in 1Panel-dev CordysCRM before 1.9.2 lets any authenticated low-privileged user read organization invoicing entities by sending POST /field/source/business-title, an endpoint that performs no permission check and therefore ignores the CONTRACT_BUSINESS_TITLE_READ privilege. Successful exploitation exposes tax identification numbers, bank account numbers, opening banks, registration addresses, and phone numbers of customer organizations, giving an attacker a ready-made dataset for invoice fraud, business email compromise, and social engineering. Publicly available exploit code exists (a Python PoC published on GitHub), and the issue is confirmed fixed in 1.9.2; per the CVSS:4.0 vector (PR:L, no UI, network-reachable), the practical barrier is simply holding valid low-privilege credentials, so an insider or a compromised standard account is enough to pull the data.
Missing authorization in 1Panel-dev CordysCRM 1.9.0 up to (but not including) 1.9.2 lets an authenticated user who has been explicitly denied module permission page through organization-wide CRM records - leads, contacts, quotations, contracts, payment plans, payment records, orders and invoices - that belong to other users. The flaw lies in eight ModuleFieldController /field/source data-source endpoints that omit the data-permission scope check, so a low-privilege account (CVSS PR:L, unauthenticated attackers cannot exploit it directly) can enumerate and read data it should never see; impact is confidentiality-only with no integrity or availability effect. Publicly available exploit code exists (a proof-of-concept script targeting the field/source endpoint family), and the vendor has released a fix in 1.9.2 via commit a31fa16f, which injects a dataPermission.invisible guard into the affected MyBatis mappers and the controller.
Command injection in MaxKB before 2.10.5-lts allows unauthenticated remote attackers to execute arbitrary shell commands when an assistant is configured with a tool, MCP tool, skill, or sub-application. Untrusted chat messages or ingested documents can coerce the LLM into invoking the un-gated `execute` shell tool, which lacks human approval and is exposed by the SandboxShellBackend. Both source deployments with MAXKB_SANDBOX disabled and the official root container's vulnerable gosu wrapper permit command execution outside the intended sandbox; no public exploit code or confirmed active exploitation was identified at time of analysis. A vendor patch is available in version 2.10.5-lts.
Cross-workspace read and modification of model parameter defaults in MaxKB 2.10.3-lts and earlier is possible for an authenticated user who holds model-read permission in a workspace they control, simply by supplying a model_id that belongs to a victim workspace. The model parameter form route checks authorization against the workspace in the URL path, but the underlying ModelSerializer.ModelParams fetches the Model by id alone without filtering on workspace_id, so the object-level check is bypassed (CWE-639, CVSS 3.1 base 7.4, AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L). Impact is bounded: it is limited to reading or overwriting the victim's model_params_form, which can indirectly alter the default behavior of workflows that consume that model, and practical exploitation requires a multi-tenant deployment plus knowledge or guessing of a valid victim model_id; no public exploit identified at time of analysis and no fixed version is available as of this review.
Authenticated workspace members on MaxKB deployments prior to 2.10.5-lts can escalate to root-level command execution by abusing how the AWS Bedrock provider stores credentials. Because MaxKB writes user-supplied access_key_id and secret_access_key values into /root/.aws/credentials without proper parsing, an attacker can smuggle control characters and a forged [profile] block containing a credential_process directive, then trigger a later model-validation request that makes botocore run an attacker-controlled command as root. Exploitation requires valid workspace credentials, the reachable Bedrock provider configuration path, and a two-step inject-then-trigger sequence on a service running with root privileges; vendor-released patch 2.10.5-lts is available and no public exploit identified at time of analysis.
CordysCRM before 1.7.2 exposes its SSE notification endpoints anonymously, allowing a remote unauthenticated attacker who can reach the backend HTTP interface to read another user's workflow events, approval requests, mentions, and alerts, inject SYSTEM_HEARTBEAT messages into that user's stream, or close that user's SSE channel. The flaw is missing authentication (CWE-306) in the Shiro public-path whitelist and the controller's trust in a caller-supplied userId; the provided source advisory CVSS 4.0 score is 9.3, while the independent CVSS 3.1 assessment is 8.6 because confidentiality impact is high but integrity and availability impact are limited to a selected user's notification stream. No CISA KEV entry or public exploit code was identified at time of analysis, but exploitation requires only network reachability and a target userId.
OS command injection in MaxKB (1Panel-dev's open-source enterprise AI assistant) before 2.10.0-lts lets an authenticated user achieve arbitrary command execution on the host by importing a crafted .tool file that declares an MCP stdio transport and triggering it through an AI Chat node. Because the tool-import path (apps/tools/serializers/tool.py) and the MCP referencing path (base_chat_step.py) fail to consistently validate the MCP transport type, the MultiServerMCPClient spawns the attacker's stdio command locally. Rated CVSS 8.8; no public exploit has been identified at time of analysis, and it is not listed in CISA KEV.
Authentication bypass in MaxKB (1Panel-dev) versions prior to 2.9.0 allows remote unauthenticated attackers to invoke webhook trigger endpoints and execute their bound tasks. The flaw stems from the WebhookAuth class unconditionally returning a successful authentication tuple, which Django REST Framework interprets as a valid identity, combined with no backend enforcement of per-trigger token requirements. No public exploit identified at time of analysis, but the trivial nature of the bypass and open-source visibility of the patch make exploitation straightforward for any attacker who can enumerate or guess trigger IDs.
MaxKB versions 2.7.1 and below allow authenticated attackers with workspace privileges to execute arbitrary code by exploiting a sandbox escape vulnerability in the ToolExecutor component. By leveraging Python's ctypes library to invoke raw system calls and bypassing the LD_PRELOAD-based sandbox.so module through the unblocked pkey_mprotect syscall, attackers can achieve remote code execution, enabling network exfiltration and container compromise. This vulnerability is confirmed fixed in version 2.8.0, and no public exploit code has been identified at time of analysis.
MaxKB versions 2.7.1 and below allow authenticated users with tool execution privileges to bypass the LD_PRELOAD-based sandbox via the env command, enabling unrestricted remote code execution and network access. The vulnerability stems from a patch that permitted execution of /usr/bin/env, which attackers can exploit using env -i to clear environment variables and drop the sandbox.so hook before spawning a native Python subprocess. Vendor-released patch: version 2.8.0.
MaxKB versions 2.7.1 and below allow authenticated users with tool-editing permissions to bypass sandbox network protection via socket.sendto() with the MSG_FASTOPEN flag, enabling connections to internal services explicitly blocked by the sandbox's banned hosts configuration. The vulnerability exploits a gap in LD_PRELOAD hooking-sendto() with MSG_FASTOPEN establishes TCP connections directly through the kernel without invoking the hooked connect() function, completely circumventing IP validation. This is a server-side request forgery (SSRF) vector that requires prior authentication and tool-editing privileges. Vendor-released patch: version 2.8.0.
Authenticated low-privileged users of CordysCRM through 1.9.3 can create or overwrite records inside custom forms they are not permitted to manage, because the POST /custom-form/data/import endpoint never verifies the caller's rights over the submitted customFormId (CWE-862). Exploitation needs only a valid low-privilege session plus an Excel file with importType set to ADD or UPDATE, and publicly available exploit code exists (a PoC script is published on GitHub); however, there is no confirmation of active exploitation (not in CISA KEV). With a CVSS 4.0 base score of 5.3 and impact confined to data integrity, this is a genuine but moderate-priority issue rather than a high-severity emergency.
Authorization bypass in CordysCRM through 1.9.3 allows low-privileged authenticated users to add follow-up records and overwrite follow_time and follower on any known customer, clue, or opportunity by setting the owner field to their own user id. Exploitation requires a valid low-privileged account and knowledge of a target record ID; the impact is limited to integrity of follow-up records with no confidentiality or availability effect. Publicly available exploit code exists, though CISA KEV does not list this as actively exploited. This is a moderate-priority authenticated-only vulnerability (CWE-639).
Broken access control in CordysCRM through 1.9.3 allows any authenticated low-privileged user to submit arbitrary business resources for approval by calling POST /approval-resource/push without any ownership check, altering approval status and exposing approval details for contracts, invoices, quotations, and orders. The flaw is remotely reachable with a valid session but requires authentication (PR:L), and impact is bounded to low confidentiality and integrity loss with no availability or system-level effect. Publicly available exploit code exists, including a proof-of-concept script, but there is no confirmation of active exploitation, and no vendor-released patch was identified in the available data at time of analysis.
Blind SSRF in CordysCRM through 1.9.3 allows any authenticated user to call POST /approval-flow/webhook/test without the required PROCESS_SETTING permission, causing the server to issue outbound requests to an attacker-supplied URL. An attacker-controlled host can redirect the request to bypass SSRFValidator and use the endpoint's success or failure results to probe internal addresses. Publicly available exploit code exists, and the assessed impact is a low-privilege broken-access-control flaw with only low confidentiality exposure and no confirmed active exploitation.
Missing authorization in CordysCRM's ContractController sort handler (POST /contract/sort) lets any authenticated user - even one without contract update permission - modify contract records, including contracts belonging to other organizations, by supplying dragNodeId, stage, and field values. The flaw is CWE-862 and affects all versions before 1.9.2; publicly available exploit code exists, though there is no confirmation of active exploitation in CISA KEV. Impact is confined to contract-record integrity (no data disclosure or service disruption), making this a moderate-severity Broken Function Level Authorization issue rather than a critical breach.
MaxKB releases prior to 2.10.6-lts allow an authenticated workspace member who can author and run function-library (tool) code to escape the built-in LD_PRELOAD syscall sandbox and act with the sandbox OS user's privileges, reading or writing files, spawning processes, and reaching networks that the sandbox was meant to block. The escape works because the sandbox's dlopen guard relied on a call-stack heuristic that can be satisfied from an importlib.abc.MetaPathFinder callback while loading ctypes, after which the real glibc syscall can be resolved with dlsym/RTLD_NEXT and invoked outside the interception layer. This is a protection-mechanism failure (CWE-693) rather than conventional unauthenticated RCE; the vendor-published score is 6.3, but the assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H because once the sandbox is defeated the escaped user's file, process, and network access is fully available. No public exploit was identified at time of analysis, and the issue is fixed in 2.10.6-lts.
An authenticated attacker with the ability to execute tool code inside MaxKB (1Panel-dev) deployments running versions prior to 2.10.6-lts can break out of the ToolExecutor subprocess sandbox and start processes that the sandbox is supposed to forbid. The escape exists because the LD_PRELOAD shim in installer/sandbox.c intercepts execve, execvpe and execveat but never hooks fexecve, leaving a gap a local tool-code executer can drive; impact is scored as limited confidentiality, integrity and availability loss (CVSS 3.1 6.3, AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L), and it is a defense-in-depth bypass rather than an initial-access vector, meaning the attacker must already have authenticated access and a code-executing tool/agent feature exposed. No public exploit code identified at time of analysis, and there is no KEV listing; the vendor has released a fix in 2.10.6-lts.
Broken object-level authorization (IDOR) in MaxKB 2.0.0 through 2.10.2-lts lets an authenticated workspace user read or modify documents and paragraphs that belong to another user's knowledge base by sending an attacker-owned knowledge_id in the request path together with a victim's document_id or paragraph_id. The affected operate routes authorize only the knowledge_id and never verify that the referenced object actually belongs to that knowledge base, so a low-privileged account plus a known victim object UUID is sufficient, with no user interaction required (CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N; base score 5.4). No public exploit code has been identified at time of analysis and no vendor-released fixed version is available, so real-world risk is moderate and firmly gated by the requirement for an authenticated account on the same deployment.
Server-side request forgery in MaxKB 2.10.3-lts and earlier allows an authenticated low-privileged workspace user (CVSS PR:L, no user interaction) to make the MaxKB server issue arbitrary HTTP requests by supplying a URL to the knowledge-base web-document import or synchronization crawler, whose Fork.fork routine calls requests.get with certificate verification disabled and no scheme, loopback, link-local, private, or reserved-address filtering. Because the fetched response body is stored as imported document content, the attacker can read the responses of reachable internal HTTP services or cloud instance metadata (e.g. AWS/GCP IMDS) rather than merely triggering blind requests, making this a full-read SSRF with confidentiality impact. There is no public exploit identified at time of analysis and no CISA KEV listing; the vendor advisory (GHSA-ffxw-frpx-8rww) reports no fixed version, so exploitation requires valid workspace credentials and reachability of interesting internal targets from the MaxKB host.
Broken authorization in MaxKB 2.7.0 through 2.10.4-lts lets an attacker who holds any valid chat token turn a victim's private conversation into a public ChatShareLink and create PublicFileAccess state that makes associated files retrievable without credentials. The POST /chat/api/{application_id}/chat/{chat_id}/share_chat handler verifies only that the conversation exists, never that it belongs to the caller's chat_user_id or to the application bound to the caller's token (CWE-285), and the exposure cannot be undone through the product because there is no revoke path. No public exploit identified at time of analysis and no vendor-released patch exists as of this review; the assessed CVSS 3.1 base score is 6.5 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N), with high attack complexity reflecting the need to know a specific, generally non-enumerable victim chat_id rather than any weakness in the request itself.
Authenticated workspace members holding only the lowest MaxKB role can bypass the per-tool denial enforced by WorkspaceUserResourcePermission and execute tools they were explicitly denied in versions 2.0.0 through 2.9.2. The bypass works by binding a denied tool's identifier through tool_ids, skill_tool_ids, or mcp_tool_ids on the agent or workflow dispatch path, which does not re-apply the grant check that the dedicated tool routes perform, and because execution decrypts server-side init_params the caller can receive credentials carried by the denied tool. The flaw requires a valid low-privilege account (CVSS vector PR:L, unauthenticated attackers are not sufficient) and knowledge or enumeration of the denied tool's identifier; there is no public exploit identified at time of analysis and no vendor patch, with the published score of 5.4 understating confidentiality impact relative to our assessment of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N.
Chat-record management routes in 1Panel-dev MaxKB 2.10.2-lts and earlier authorize only the application_id supplied in the request path, then load chat data using globally scoped chat_id and chat_record_id values without confirming that the chat actually belongs to that application, so a low-privileged authenticated user in the same workspace can read a victim's persisted chat records by re-homing a known chat_id under an application they own. Impact is limited (CVSS 4.2, C:L/I:L), the attack is network-reachable but requires an authenticated normal account in the victim's workspace and prior knowledge or enumeration of valid global chat identifiers, which is the dominant practical hurdle. A second variant uses the add_knowledge flow, available to any user with an owned knowledge base and document, to copy victim answers while overwriting the victim record's improve_paragraph_id_list. No public exploit code has been identified at time of analysis and no fixed version was available as of review; despite the supplied 'Authentication Bypass' tag, this is an object-level authorization/IDOR defect rather than a true auth bypass.
Missing object-level authorization in MaxKB 2.10.2-lts and earlier lets an authenticated, non-privileged user of a workspace read another user's hidden MCP tool record - including the Tool.code field, which can embed MCP server configuration and headers - by requesting the tool-detail route with a known tool_id. The same weakness permits a secondary abuse path: a user who can create or edit their own workflow can reference the foreign mcp_tool_id in a workflow MCP node so that workflow debug executes with the victim's MCP configuration without any permission check. The flaw is confined to members of the same workspace and requires prior knowledge of a valid tool_id, and no public exploit identified at time of analysis; no fixed version is available as of this review.
Missing authorization checks in the MaxKB enterprise AI assistant (2.10.2-lts and earlier) let an authenticated normal user in the same workspace harvest another user's application_id from the homepage application question-ranking endpoint, then place that identifier into an application-node of an attacker-owned published workflow application to obtain output generated by the victim application and create durable application_chat and application_chat_record rows under it. Exploitation is constrained: the victim application must be published and show ranking activity in the attacker-selected date range, the attacker must know or guess its name, and direct application-detail and debug-open routes continue to deny access - only the ranking endpoint leaks the identifier - and it requires a valid workspace account (CVSS 3.1 AV:N/PR:L, score 5.4). No public exploit identified at time of analysis and no fixed version is available as of this review.
MaxKB 2.10.2-lts and earlier accepts expired non-permanent ApplicationApiKey credentials on the /chat/api/mcp endpoint, allowing an authenticated attacker who already holds such a key secret to initialize the MCP interface, enumerate the published application's tool metadata, invoke tools/call, and persist application_chat and application_chat_record records - operations the standard /chat/api/open path refuses with the same key. The root cause is CWE-613 (Insufficient Session Expiration): the MCP authentication path validates only the key secret and its active flag while omitting the is_permanent and expire_time checks enforced elsewhere. This is a bounded credential-lifecycle bypass rather than unauthenticated access - the attacker must already possess a leaked, retained, or previously delegated key that is still marked active and past its expiry - and no public exploit has been identified at time of analysis, with no vendor-released patch identified at time of analysis.
Error-based SQL injection in CordysCRM 1.7.0 through pre-1.7.4 lets an authenticated user holding the MODULE_SETTING_UPDATE permission inject database functions into the sort parameter of POST /account-pool/page, exposing database values through an error oracle when the query returns at least one row. No public exploit code is identified at time of analysis, and the independently assessed impact is confidentiality-only (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N). The vendor fixed the flaw in version 1.7.4.
Unauthenticated tenants can read other organizations' uploaded files in CordysCRM (1Panel-dev) versions prior to 1.7.4, because the Shiro-configured anonymous routes /attachment/preview/{id} and /pic/preview/{id} resolve attachments through AttachmentService.getResource with a bare primary-key lookup and no ownership, organization, or permission check. Exploitation requires the attacker to know, guess, or observe a valid IDGenerator.nextStr file id; the ids are not sequentially predictable, which raises attack complexity, but ids leaked through shared preview links, logs, or browser history permit direct retrieval. The issue is read-only disclosure of stored files and is fixed in 1.7.4; no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis. This is a genuine unauthenticated broken-access-control (IDOR) flaw but a moderate real-world priority, not a critical emergency.
CordysCRM 1.7.3 and earlier allows an authenticated user holding the PROCESS_SETTING_ADD permission to store an attacker-chosen webhook URL in an approval-flow node and then cause the server to issue outbound HTTP requests to that URL when an approval action is approved, turning the application into a proxy for reaching internal-only services. The assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N - high confidentiality impact against the attacked component with no integrity or availability impact - and the practical payoff is cloud metadata access (for example 169.254.169.254) and internal network reconnaissance, bounded by the server's network reach and by the multi-step trigger (configure via POST /approval-flow/add, fire via POST /approval-action/approve). The flaw is fixed in 1.7.4 per vendor advisory GHSA-fg6q-pfj7-fghw, PR #2966 and commit e0ae23e; no public exploit code and no confirmed active exploitation were identified at time of analysis, and exploitation requires a low-privileged authenticated account plus a second in-application approval step.
Broken object-level authorization (IDOR/BOLA) in CordysCRM allows any authenticated user holding the ordinary CLUE_MANAGEMENT_POOL:READ or CUSTOMER_MANAGEMENT_POOL:READ permission to read leads and customer accounts belonging to other users, departments, or organizations by supplying an arbitrary record ID to GET /pool/lead/get/{id} or GET /pool/account/get/{id}. The flaw affects all CordysCRM deployments prior to version 1.7.4 and is read-only in effect, but it exposes highly sensitive CRM data including contact names, phone numbers, owner and department attribution, and custom field values, with no special privileges, administrative rights, or non-default configuration required beyond valid credentials. No public exploit code has been identified at time of analysis and there is no CISA KEV listing, so this is an authenticated information-disclosure issue rather than an RCE-class emergency, though the confidence is high because the affected code path is the default behavior of every pre-1.7.4 install.
Unauthenticated information disclosure in CordysCRM (1Panel-dev) versions prior to 1.7.2 lets any network-reachable caller retrieve CRM form metadata via GET /mcp/form/config/{formKey}, exposing field names, types, required flags, default values, options, validation rules, and binding sources. The flaw exists because ShiroFilter marks the /mcp/** path as anonymous and McpController.getMcpField carries no permission annotation, so the endpoint is reachable without credentials (CVSS 4.0 base 6.9; independent assessment CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). Impact is limited to schema/metadata disclosure rather than direct access to customer records, and no public exploit code has been identified at time of analysis; exploitation does require knowledge or brute-forcing of valid formKey identifiers.
Time-based blind SQL injection in CordysCRM versions prior to 1.7.0 allows an authenticated attacker holding the MODULE_SETTING:UPDATE permission to inject SQL into the ORDER BY clause via the sort.name field of the POST /account-pool/page endpoint, enabling inference of database metadata and sensitive values through induced delays and causing service degradation. Exploitation requires a privileged, trusted account and the blind nature of the flaw makes data extraction slow, so this is a genuine but modest-priority issue rather than a mass-exploitable one. No public exploit code has been identified at time of analysis, and the flaw is fixed in release 1.7.0 (GHSA-xrcr-hj37-q83j).
Server-side request forgery in MaxKB versions 2.0.0 through 2.10.4-lts allows authenticated workspace users to proxy HTTP requests through the application server to internal infrastructure, loopback addresses, link-local networks, and cloud instance metadata endpoints such as the AWS IMDSv1 service. The vulnerable code paths in both template workflow handlers and tool update functions pass caller-supplied download_url and download_callback_url values directly to requests.get protected only by a weak startsWith prefix check, which is insufficient to block hostname-confusion or open-redirect bypasses. No public exploit has been identified at time of analysis, and the upstream fix on the v2 branch has not yet been packaged into a published release.
Server-side request forgery in CordysCRM (1Panel-dev) up to version 1.4.1 allows authenticated remote attackers to coerce the application server into issuing outbound HTTP requests to arbitrary destinations by manipulating the `appSecret` parameter in the Third Party Edit Endpoint's `getSqlBotSrc` function. This can expose internal network services, cloud instance metadata endpoints, and other non-public resources to an attacker with only a low-privileged account. A public exploit has been disclosed (GitHub issue #2688), meaning exploitation requires minimal technical skill beyond valid credentials.
Server-side request forgery in CordysCRM (by 1Panel-dev) up to version 1.4.1 allows low-privileged remote attackers to manipulate the mkAddress parameter in the Third Party Endpoint's SSO token service, causing the application server to issue unauthorized HTTP requests to attacker-controlled destinations. The affected component is TokenService.java within the CRM's SSO integration layer, meaning exploitation could expose internal network topology or interact with internal services unreachable from the public internet. A public proof-of-concept exploit exists; the project vendor closed the issue report without acknowledging it as a valid security vulnerability, leaving no official remediation path confirmed.
Server-side request forgery in MaxKB before 2.10.0 allows any authenticated user holding the default workspace USER role to coerce the application server into making arbitrary HTTP requests to attacker-controlled destinations via the `downloadCallbackUrl` and `download_url` parameters on ToolSerializer endpoints. An attacker can pivot through the MaxKB host to probe and extract data from internal network services - cloud metadata APIs, internal databases, adjacent microservices - that would otherwise be inaccessible from outside the network perimeter. A public proof-of-concept exists at GitHub issue #6272; this is not confirmed actively exploited (not in CISA KEV).
Stored cross-site scripting in CordysCRM (1Panel-dev, versions up to 1.4.1) allows an authenticated remote attacker to inject malicious scripts via the unvalidated Description parameter in the ModuleFormController's Save function. The payload persists to the database and executes in any victim's browser upon viewing the affected module form, enabling session hijacking, credential theft, or UI-based phishing. A publicly available proof-of-concept exists (GitHub issue #2233); no public exploitation at scale has been confirmed, and an official vendor patch is available as of v1.7.0.
Authenticated SSRF bypass in MaxKB's OSS file service URL fetch allows low-privilege users to reach internal network services by exploiting inconsistent DNS resolution between validation and request execution. MaxKB 2.8.0 and all prior versions are affected; the attacker causes the validation step to resolve a domain to a public IP, then swaps the DNS record so the actual HTTP fetch resolves to an internal address, bypassing the SSRF filter entirely. No public exploit has been identified and this CVE is not listed in CISA KEV; a vendor-released patch (2.8.1) is available.
Broken access control in MaxKB 2.8.0 and earlier exposes the OSS file service URL fetch API (`chat/api/oss/get_url`) to cross-application data access by authenticated low-privilege users who supply arbitrary `application_id` values in the URL path. Because the endpoint performs no ownership validation against the requesting session, any authenticated user can retrieve OSS file URLs scoped to applications they do not own, violating multi-tenant isolation. No public exploit code exists and the issue is not listed in CISA KEV; a vendor-released patch is available in version 2.8.1.
Server-Side Request Forgery in MaxKB before 2.9.1 allows authenticated users to pivot into internal network infrastructure by supplying arbitrary URLs to the work_flow_template import endpoint. The server fetches attacker-controlled URLs without validation or internal IP filtering, enabling reconnaissance of internal services, cloud metadata endpoints, or other resources unreachable from the public internet. The CVSS 4.0 score of 6.3 is driven primarily by high subsequent-system confidentiality impact (SC:H), reflecting the lateral reach into backend infrastructure that SSRF typically enables. No public exploit code or active exploitation has been identified at time of analysis.
MaxKB, an open-source enterprise AI assistant by 1Panel-dev, stores user passwords as unsalted MD5 hashes, exposing all user credentials to trivial offline cracking upon any database compromise. All versions prior to 2.9.1 are affected (CPE: cpe:2.3:a:1panel-dev:maxkb). The CVSS 4.0 vector (AV:L/VC:H) confirms that while local or database-level access is a prerequisite, once hashes are obtained, full credential recovery is practically guaranteed using rainbow tables or GPU-accelerated tools such as hashcat - no public exploit identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Server-side request forgery in MaxKB v2.8.0 and earlier allows authenticated low-privilege users to reach internal network services by exploiting an URL parsing inconsistency at the OSS file fetch endpoint. The discrepancy between Python's urlparse validation logic and the requests HTTP client means a crafted URL can pass security checks yet still route to internal infrastructure when executed by the server. No public exploit or KEV listing exists at time of analysis; the vendor has confirmed and patched the issue in 2.8.1.
Stored Cross-Site Scripting in MaxKB's MdRenderer component allows authenticated users to inject malicious scripts via custom <iframe_render> tags in LLM responses or Application Prologue configurations, leading to JavaScript execution in the parent window context with access to session tokens and sensitive data. MaxKB versions 2.7.1 and earlier are affected; the vulnerability is fixed in version 2.8.0. The attack requires user interaction (UI:P) but impacts all visitors to an affected application's chat interface, making it a high-impact stored XSS despite the moderate CVSS 5.1 score.
Stored Cross-Site Scripting in MaxKB 2.7.1 and below allows authenticated users to inject arbitrary JavaScript into the Application prologue field via <html_rander> tags, which the backend stores unsanitized and the frontend renders with innerHTML-equivalent mechanisms. Exploitation enables session hijacking, unauthorized workspace/application deletion, and sensitive data exposure against any visitor accessing the affected chatbot. Fixed in version 2.8.0.
MaxKB versions 2.7.1 and below allow authenticated users to spoof tool execution results by exploiting Python frame introspection to extract the wrapper's UUID from bytecode, then writing forged output directly to file descriptor 1 to bypass stdout redirection and terminate the wrapper process before legitimate output is generated, causing the service to trust the attacker-controlled response. This integrity bypass requires prior authentication and local/network access but enables attackers to manipulate AI tool results without detection. The vulnerability has been patched in version 2.8.0.
MaxKB versions 2.7.1 and below allow authenticated administrators to trigger arbitrary code execution on their own workstations through improper CSV formula sanitization in the chat export feature. When exporting chat history to Excel via the /admin/api/workspace/{workspace_id}/application/{application_id}/chat/export endpoint, formula strings (e.g., =cmd|'/c calc'!A1) are written unsanitized to the .xlsx file, enabling Dynamic Data Exchange (DDE) exploitation when the file is opened in Microsoft Excel. No public exploit code has been identified, but the vulnerability represents a high-impact attack path for administrators with legitimate export access and is a direct repeat of a previously patched flaw (CVE-2025-4546) that was incompletely remediated across the codebase.
Stored Cross-Site Scripting (XSS) via Eval Injection in MaxKB's Markdown rendering engine allows authenticated users to execute arbitrary JavaScript in other users' browsers, including administrators. MaxKB versions 2.7.1 and below are affected. The vulnerability requires user interaction (UI:P) and low privileges (PR:L) to exploit, but delivers high integrity impact (VI:H) to victim sessions. A vendor-released patch is available in version 2.8.0.
Stored Cross-Site Scripting (XSS) in MaxKB 2.7.1 and below allows authenticated users to inject malicious JavaScript through application name or icon fields, which is then executed in victims' browsers when accessing the public chat interface. The vulnerability stems from unsanitized data insertion into HTML responses by ChatHeadersMiddleware, enabling arbitrary code execution with user interaction. MaxKB 2.8.0 has released a patch to fix this issue.
Cross-site scripting (XSS) in 1Panel-dev MaxKB up to version 2.4.2 allows authenticated remote attackers to inject malicious scripts via the MdPreview component in ui/src/chat.ts, requiring user interaction to execute. Publicly available exploit code exists for this vulnerability. The vendor released patched version 2.5.0 addressing the flaw with commit 7230daa5ec3e6574b6ede83dd48a4fbc0e70b8d8.
OS command injection in 1Panel-dev MaxKB up to version 2.6.1 allows authenticated remote attackers to execute arbitrary operating system commands through manipulation of the Model Context Protocol Node's execute function in base_mcp_node.py, with publicly available exploit code and vendor-released patches available for remediation.
Stored cross-site scripting (XSS) in 1Panel-dev MaxKB up to version 2.6.1 allows authenticated remote attackers to inject malicious scripts via the Name argument in ChatHeadersMiddleware, requiring user interaction to trigger. The vulnerability has a low CVSS score (3.5) due to requiring authentication and user interaction, but XSS can lead to session hijacking or credential theft. Vendor-released patch version 2.8.0 addresses this issue.
Cross-site scripting (XSS) in 1Panel-dev MaxKB up to version 2.2.1 allows authenticated remote attackers to inject malicious scripts via the Name argument in the StaticHeadersMiddleware component of the Public Chat Interface. The vulnerability requires user interaction (UI:R) and has low confidentiality impact but enables persistent code execution in user browsers. Publicly available exploit code exists, and vendor-released patch version 2.8.0 resolves the issue.
Missing authorization in 1Panel-dev CordysCRM before 1.9.2 lets any authenticated low-privileged user read organization invoicing entities by sending POST /field/source/business-title, an endpoint that performs no permission check and therefore ignores the CONTRACT_BUSINESS_TITLE_READ privilege. Successful exploitation exposes tax identification numbers, bank account numbers, opening banks, registration addresses, and phone numbers of customer organizations, giving an attacker a ready-made dataset for invoice fraud, business email compromise, and social engineering. Publicly available exploit code exists (a Python PoC published on GitHub), and the issue is confirmed fixed in 1.9.2; per the CVSS:4.0 vector (PR:L, no UI, network-reachable), the practical barrier is simply holding valid low-privilege credentials, so an insider or a compromised standard account is enough to pull the data.
Missing authorization in 1Panel-dev CordysCRM 1.9.0 up to (but not including) 1.9.2 lets an authenticated user who has been explicitly denied module permission page through organization-wide CRM records - leads, contacts, quotations, contracts, payment plans, payment records, orders and invoices - that belong to other users. The flaw lies in eight ModuleFieldController /field/source data-source endpoints that omit the data-permission scope check, so a low-privilege account (CVSS PR:L, unauthenticated attackers cannot exploit it directly) can enumerate and read data it should never see; impact is confidentiality-only with no integrity or availability effect. Publicly available exploit code exists (a proof-of-concept script targeting the field/source endpoint family), and the vendor has released a fix in 1.9.2 via commit a31fa16f, which injects a dataPermission.invisible guard into the affected MyBatis mappers and the controller.
Command injection in MaxKB before 2.10.5-lts allows unauthenticated remote attackers to execute arbitrary shell commands when an assistant is configured with a tool, MCP tool, skill, or sub-application. Untrusted chat messages or ingested documents can coerce the LLM into invoking the un-gated `execute` shell tool, which lacks human approval and is exposed by the SandboxShellBackend. Both source deployments with MAXKB_SANDBOX disabled and the official root container's vulnerable gosu wrapper permit command execution outside the intended sandbox; no public exploit code or confirmed active exploitation was identified at time of analysis. A vendor patch is available in version 2.10.5-lts.
Cross-workspace read and modification of model parameter defaults in MaxKB 2.10.3-lts and earlier is possible for an authenticated user who holds model-read permission in a workspace they control, simply by supplying a model_id that belongs to a victim workspace. The model parameter form route checks authorization against the workspace in the URL path, but the underlying ModelSerializer.ModelParams fetches the Model by id alone without filtering on workspace_id, so the object-level check is bypassed (CWE-639, CVSS 3.1 base 7.4, AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L). Impact is bounded: it is limited to reading or overwriting the victim's model_params_form, which can indirectly alter the default behavior of workflows that consume that model, and practical exploitation requires a multi-tenant deployment plus knowledge or guessing of a valid victim model_id; no public exploit identified at time of analysis and no fixed version is available as of this review.
Authenticated workspace members on MaxKB deployments prior to 2.10.5-lts can escalate to root-level command execution by abusing how the AWS Bedrock provider stores credentials. Because MaxKB writes user-supplied access_key_id and secret_access_key values into /root/.aws/credentials without proper parsing, an attacker can smuggle control characters and a forged [profile] block containing a credential_process directive, then trigger a later model-validation request that makes botocore run an attacker-controlled command as root. Exploitation requires valid workspace credentials, the reachable Bedrock provider configuration path, and a two-step inject-then-trigger sequence on a service running with root privileges; vendor-released patch 2.10.5-lts is available and no public exploit identified at time of analysis.
CordysCRM before 1.7.2 exposes its SSE notification endpoints anonymously, allowing a remote unauthenticated attacker who can reach the backend HTTP interface to read another user's workflow events, approval requests, mentions, and alerts, inject SYSTEM_HEARTBEAT messages into that user's stream, or close that user's SSE channel. The flaw is missing authentication (CWE-306) in the Shiro public-path whitelist and the controller's trust in a caller-supplied userId; the provided source advisory CVSS 4.0 score is 9.3, while the independent CVSS 3.1 assessment is 8.6 because confidentiality impact is high but integrity and availability impact are limited to a selected user's notification stream. No CISA KEV entry or public exploit code was identified at time of analysis, but exploitation requires only network reachability and a target userId.
OS command injection in MaxKB (1Panel-dev's open-source enterprise AI assistant) before 2.10.0-lts lets an authenticated user achieve arbitrary command execution on the host by importing a crafted .tool file that declares an MCP stdio transport and triggering it through an AI Chat node. Because the tool-import path (apps/tools/serializers/tool.py) and the MCP referencing path (base_chat_step.py) fail to consistently validate the MCP transport type, the MultiServerMCPClient spawns the attacker's stdio command locally. Rated CVSS 8.8; no public exploit has been identified at time of analysis, and it is not listed in CISA KEV.
Authentication bypass in MaxKB (1Panel-dev) versions prior to 2.9.0 allows remote unauthenticated attackers to invoke webhook trigger endpoints and execute their bound tasks. The flaw stems from the WebhookAuth class unconditionally returning a successful authentication tuple, which Django REST Framework interprets as a valid identity, combined with no backend enforcement of per-trigger token requirements. No public exploit identified at time of analysis, but the trivial nature of the bypass and open-source visibility of the patch make exploitation straightforward for any attacker who can enumerate or guess trigger IDs.
MaxKB versions 2.7.1 and below allow authenticated attackers with workspace privileges to execute arbitrary code by exploiting a sandbox escape vulnerability in the ToolExecutor component. By leveraging Python's ctypes library to invoke raw system calls and bypassing the LD_PRELOAD-based sandbox.so module through the unblocked pkey_mprotect syscall, attackers can achieve remote code execution, enabling network exfiltration and container compromise. This vulnerability is confirmed fixed in version 2.8.0, and no public exploit code has been identified at time of analysis.
MaxKB versions 2.7.1 and below allow authenticated users with tool execution privileges to bypass the LD_PRELOAD-based sandbox via the env command, enabling unrestricted remote code execution and network access. The vulnerability stems from a patch that permitted execution of /usr/bin/env, which attackers can exploit using env -i to clear environment variables and drop the sandbox.so hook before spawning a native Python subprocess. Vendor-released patch: version 2.8.0.
MaxKB versions 2.7.1 and below allow authenticated users with tool-editing permissions to bypass sandbox network protection via socket.sendto() with the MSG_FASTOPEN flag, enabling connections to internal services explicitly blocked by the sandbox's banned hosts configuration. The vulnerability exploits a gap in LD_PRELOAD hooking-sendto() with MSG_FASTOPEN establishes TCP connections directly through the kernel without invoking the hooked connect() function, completely circumventing IP validation. This is a server-side request forgery (SSRF) vector that requires prior authentication and tool-editing privileges. Vendor-released patch: version 2.8.0.
Authenticated low-privileged users of CordysCRM through 1.9.3 can create or overwrite records inside custom forms they are not permitted to manage, because the POST /custom-form/data/import endpoint never verifies the caller's rights over the submitted customFormId (CWE-862). Exploitation needs only a valid low-privilege session plus an Excel file with importType set to ADD or UPDATE, and publicly available exploit code exists (a PoC script is published on GitHub); however, there is no confirmation of active exploitation (not in CISA KEV). With a CVSS 4.0 base score of 5.3 and impact confined to data integrity, this is a genuine but moderate-priority issue rather than a high-severity emergency.
Authorization bypass in CordysCRM through 1.9.3 allows low-privileged authenticated users to add follow-up records and overwrite follow_time and follower on any known customer, clue, or opportunity by setting the owner field to their own user id. Exploitation requires a valid low-privileged account and knowledge of a target record ID; the impact is limited to integrity of follow-up records with no confidentiality or availability effect. Publicly available exploit code exists, though CISA KEV does not list this as actively exploited. This is a moderate-priority authenticated-only vulnerability (CWE-639).
Broken access control in CordysCRM through 1.9.3 allows any authenticated low-privileged user to submit arbitrary business resources for approval by calling POST /approval-resource/push without any ownership check, altering approval status and exposing approval details for contracts, invoices, quotations, and orders. The flaw is remotely reachable with a valid session but requires authentication (PR:L), and impact is bounded to low confidentiality and integrity loss with no availability or system-level effect. Publicly available exploit code exists, including a proof-of-concept script, but there is no confirmation of active exploitation, and no vendor-released patch was identified in the available data at time of analysis.
Blind SSRF in CordysCRM through 1.9.3 allows any authenticated user to call POST /approval-flow/webhook/test without the required PROCESS_SETTING permission, causing the server to issue outbound requests to an attacker-supplied URL. An attacker-controlled host can redirect the request to bypass SSRFValidator and use the endpoint's success or failure results to probe internal addresses. Publicly available exploit code exists, and the assessed impact is a low-privilege broken-access-control flaw with only low confidentiality exposure and no confirmed active exploitation.
Missing authorization in CordysCRM's ContractController sort handler (POST /contract/sort) lets any authenticated user - even one without contract update permission - modify contract records, including contracts belonging to other organizations, by supplying dragNodeId, stage, and field values. The flaw is CWE-862 and affects all versions before 1.9.2; publicly available exploit code exists, though there is no confirmation of active exploitation in CISA KEV. Impact is confined to contract-record integrity (no data disclosure or service disruption), making this a moderate-severity Broken Function Level Authorization issue rather than a critical breach.
MaxKB releases prior to 2.10.6-lts allow an authenticated workspace member who can author and run function-library (tool) code to escape the built-in LD_PRELOAD syscall sandbox and act with the sandbox OS user's privileges, reading or writing files, spawning processes, and reaching networks that the sandbox was meant to block. The escape works because the sandbox's dlopen guard relied on a call-stack heuristic that can be satisfied from an importlib.abc.MetaPathFinder callback while loading ctypes, after which the real glibc syscall can be resolved with dlsym/RTLD_NEXT and invoked outside the interception layer. This is a protection-mechanism failure (CWE-693) rather than conventional unauthenticated RCE; the vendor-published score is 6.3, but the assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H because once the sandbox is defeated the escaped user's file, process, and network access is fully available. No public exploit was identified at time of analysis, and the issue is fixed in 2.10.6-lts.
An authenticated attacker with the ability to execute tool code inside MaxKB (1Panel-dev) deployments running versions prior to 2.10.6-lts can break out of the ToolExecutor subprocess sandbox and start processes that the sandbox is supposed to forbid. The escape exists because the LD_PRELOAD shim in installer/sandbox.c intercepts execve, execvpe and execveat but never hooks fexecve, leaving a gap a local tool-code executer can drive; impact is scored as limited confidentiality, integrity and availability loss (CVSS 3.1 6.3, AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L), and it is a defense-in-depth bypass rather than an initial-access vector, meaning the attacker must already have authenticated access and a code-executing tool/agent feature exposed. No public exploit code identified at time of analysis, and there is no KEV listing; the vendor has released a fix in 2.10.6-lts.
Broken object-level authorization (IDOR) in MaxKB 2.0.0 through 2.10.2-lts lets an authenticated workspace user read or modify documents and paragraphs that belong to another user's knowledge base by sending an attacker-owned knowledge_id in the request path together with a victim's document_id or paragraph_id. The affected operate routes authorize only the knowledge_id and never verify that the referenced object actually belongs to that knowledge base, so a low-privileged account plus a known victim object UUID is sufficient, with no user interaction required (CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N; base score 5.4). No public exploit code has been identified at time of analysis and no vendor-released fixed version is available, so real-world risk is moderate and firmly gated by the requirement for an authenticated account on the same deployment.
Server-side request forgery in MaxKB 2.10.3-lts and earlier allows an authenticated low-privileged workspace user (CVSS PR:L, no user interaction) to make the MaxKB server issue arbitrary HTTP requests by supplying a URL to the knowledge-base web-document import or synchronization crawler, whose Fork.fork routine calls requests.get with certificate verification disabled and no scheme, loopback, link-local, private, or reserved-address filtering. Because the fetched response body is stored as imported document content, the attacker can read the responses of reachable internal HTTP services or cloud instance metadata (e.g. AWS/GCP IMDS) rather than merely triggering blind requests, making this a full-read SSRF with confidentiality impact. There is no public exploit identified at time of analysis and no CISA KEV listing; the vendor advisory (GHSA-ffxw-frpx-8rww) reports no fixed version, so exploitation requires valid workspace credentials and reachability of interesting internal targets from the MaxKB host.
Broken authorization in MaxKB 2.7.0 through 2.10.4-lts lets an attacker who holds any valid chat token turn a victim's private conversation into a public ChatShareLink and create PublicFileAccess state that makes associated files retrievable without credentials. The POST /chat/api/{application_id}/chat/{chat_id}/share_chat handler verifies only that the conversation exists, never that it belongs to the caller's chat_user_id or to the application bound to the caller's token (CWE-285), and the exposure cannot be undone through the product because there is no revoke path. No public exploit identified at time of analysis and no vendor-released patch exists as of this review; the assessed CVSS 3.1 base score is 6.5 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N), with high attack complexity reflecting the need to know a specific, generally non-enumerable victim chat_id rather than any weakness in the request itself.
Authenticated workspace members holding only the lowest MaxKB role can bypass the per-tool denial enforced by WorkspaceUserResourcePermission and execute tools they were explicitly denied in versions 2.0.0 through 2.9.2. The bypass works by binding a denied tool's identifier through tool_ids, skill_tool_ids, or mcp_tool_ids on the agent or workflow dispatch path, which does not re-apply the grant check that the dedicated tool routes perform, and because execution decrypts server-side init_params the caller can receive credentials carried by the denied tool. The flaw requires a valid low-privilege account (CVSS vector PR:L, unauthenticated attackers are not sufficient) and knowledge or enumeration of the denied tool's identifier; there is no public exploit identified at time of analysis and no vendor patch, with the published score of 5.4 understating confidentiality impact relative to our assessment of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N.
Chat-record management routes in 1Panel-dev MaxKB 2.10.2-lts and earlier authorize only the application_id supplied in the request path, then load chat data using globally scoped chat_id and chat_record_id values without confirming that the chat actually belongs to that application, so a low-privileged authenticated user in the same workspace can read a victim's persisted chat records by re-homing a known chat_id under an application they own. Impact is limited (CVSS 4.2, C:L/I:L), the attack is network-reachable but requires an authenticated normal account in the victim's workspace and prior knowledge or enumeration of valid global chat identifiers, which is the dominant practical hurdle. A second variant uses the add_knowledge flow, available to any user with an owned knowledge base and document, to copy victim answers while overwriting the victim record's improve_paragraph_id_list. No public exploit code has been identified at time of analysis and no fixed version was available as of review; despite the supplied 'Authentication Bypass' tag, this is an object-level authorization/IDOR defect rather than a true auth bypass.
Missing object-level authorization in MaxKB 2.10.2-lts and earlier lets an authenticated, non-privileged user of a workspace read another user's hidden MCP tool record - including the Tool.code field, which can embed MCP server configuration and headers - by requesting the tool-detail route with a known tool_id. The same weakness permits a secondary abuse path: a user who can create or edit their own workflow can reference the foreign mcp_tool_id in a workflow MCP node so that workflow debug executes with the victim's MCP configuration without any permission check. The flaw is confined to members of the same workspace and requires prior knowledge of a valid tool_id, and no public exploit identified at time of analysis; no fixed version is available as of this review.
Missing authorization checks in the MaxKB enterprise AI assistant (2.10.2-lts and earlier) let an authenticated normal user in the same workspace harvest another user's application_id from the homepage application question-ranking endpoint, then place that identifier into an application-node of an attacker-owned published workflow application to obtain output generated by the victim application and create durable application_chat and application_chat_record rows under it. Exploitation is constrained: the victim application must be published and show ranking activity in the attacker-selected date range, the attacker must know or guess its name, and direct application-detail and debug-open routes continue to deny access - only the ranking endpoint leaks the identifier - and it requires a valid workspace account (CVSS 3.1 AV:N/PR:L, score 5.4). No public exploit identified at time of analysis and no fixed version is available as of this review.
MaxKB 2.10.2-lts and earlier accepts expired non-permanent ApplicationApiKey credentials on the /chat/api/mcp endpoint, allowing an authenticated attacker who already holds such a key secret to initialize the MCP interface, enumerate the published application's tool metadata, invoke tools/call, and persist application_chat and application_chat_record records - operations the standard /chat/api/open path refuses with the same key. The root cause is CWE-613 (Insufficient Session Expiration): the MCP authentication path validates only the key secret and its active flag while omitting the is_permanent and expire_time checks enforced elsewhere. This is a bounded credential-lifecycle bypass rather than unauthenticated access - the attacker must already possess a leaked, retained, or previously delegated key that is still marked active and past its expiry - and no public exploit has been identified at time of analysis, with no vendor-released patch identified at time of analysis.
Error-based SQL injection in CordysCRM 1.7.0 through pre-1.7.4 lets an authenticated user holding the MODULE_SETTING_UPDATE permission inject database functions into the sort parameter of POST /account-pool/page, exposing database values through an error oracle when the query returns at least one row. No public exploit code is identified at time of analysis, and the independently assessed impact is confidentiality-only (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N). The vendor fixed the flaw in version 1.7.4.
Unauthenticated tenants can read other organizations' uploaded files in CordysCRM (1Panel-dev) versions prior to 1.7.4, because the Shiro-configured anonymous routes /attachment/preview/{id} and /pic/preview/{id} resolve attachments through AttachmentService.getResource with a bare primary-key lookup and no ownership, organization, or permission check. Exploitation requires the attacker to know, guess, or observe a valid IDGenerator.nextStr file id; the ids are not sequentially predictable, which raises attack complexity, but ids leaked through shared preview links, logs, or browser history permit direct retrieval. The issue is read-only disclosure of stored files and is fixed in 1.7.4; no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis. This is a genuine unauthenticated broken-access-control (IDOR) flaw but a moderate real-world priority, not a critical emergency.
CordysCRM 1.7.3 and earlier allows an authenticated user holding the PROCESS_SETTING_ADD permission to store an attacker-chosen webhook URL in an approval-flow node and then cause the server to issue outbound HTTP requests to that URL when an approval action is approved, turning the application into a proxy for reaching internal-only services. The assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N - high confidentiality impact against the attacked component with no integrity or availability impact - and the practical payoff is cloud metadata access (for example 169.254.169.254) and internal network reconnaissance, bounded by the server's network reach and by the multi-step trigger (configure via POST /approval-flow/add, fire via POST /approval-action/approve). The flaw is fixed in 1.7.4 per vendor advisory GHSA-fg6q-pfj7-fghw, PR #2966 and commit e0ae23e; no public exploit code and no confirmed active exploitation were identified at time of analysis, and exploitation requires a low-privileged authenticated account plus a second in-application approval step.
Broken object-level authorization (IDOR/BOLA) in CordysCRM allows any authenticated user holding the ordinary CLUE_MANAGEMENT_POOL:READ or CUSTOMER_MANAGEMENT_POOL:READ permission to read leads and customer accounts belonging to other users, departments, or organizations by supplying an arbitrary record ID to GET /pool/lead/get/{id} or GET /pool/account/get/{id}. The flaw affects all CordysCRM deployments prior to version 1.7.4 and is read-only in effect, but it exposes highly sensitive CRM data including contact names, phone numbers, owner and department attribution, and custom field values, with no special privileges, administrative rights, or non-default configuration required beyond valid credentials. No public exploit code has been identified at time of analysis and there is no CISA KEV listing, so this is an authenticated information-disclosure issue rather than an RCE-class emergency, though the confidence is high because the affected code path is the default behavior of every pre-1.7.4 install.
Unauthenticated information disclosure in CordysCRM (1Panel-dev) versions prior to 1.7.2 lets any network-reachable caller retrieve CRM form metadata via GET /mcp/form/config/{formKey}, exposing field names, types, required flags, default values, options, validation rules, and binding sources. The flaw exists because ShiroFilter marks the /mcp/** path as anonymous and McpController.getMcpField carries no permission annotation, so the endpoint is reachable without credentials (CVSS 4.0 base 6.9; independent assessment CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). Impact is limited to schema/metadata disclosure rather than direct access to customer records, and no public exploit code has been identified at time of analysis; exploitation does require knowledge or brute-forcing of valid formKey identifiers.
Time-based blind SQL injection in CordysCRM versions prior to 1.7.0 allows an authenticated attacker holding the MODULE_SETTING:UPDATE permission to inject SQL into the ORDER BY clause via the sort.name field of the POST /account-pool/page endpoint, enabling inference of database metadata and sensitive values through induced delays and causing service degradation. Exploitation requires a privileged, trusted account and the blind nature of the flaw makes data extraction slow, so this is a genuine but modest-priority issue rather than a mass-exploitable one. No public exploit code has been identified at time of analysis, and the flaw is fixed in release 1.7.0 (GHSA-xrcr-hj37-q83j).
Server-side request forgery in MaxKB versions 2.0.0 through 2.10.4-lts allows authenticated workspace users to proxy HTTP requests through the application server to internal infrastructure, loopback addresses, link-local networks, and cloud instance metadata endpoints such as the AWS IMDSv1 service. The vulnerable code paths in both template workflow handlers and tool update functions pass caller-supplied download_url and download_callback_url values directly to requests.get protected only by a weak startsWith prefix check, which is insufficient to block hostname-confusion or open-redirect bypasses. No public exploit has been identified at time of analysis, and the upstream fix on the v2 branch has not yet been packaged into a published release.
Server-side request forgery in CordysCRM (1Panel-dev) up to version 1.4.1 allows authenticated remote attackers to coerce the application server into issuing outbound HTTP requests to arbitrary destinations by manipulating the `appSecret` parameter in the Third Party Edit Endpoint's `getSqlBotSrc` function. This can expose internal network services, cloud instance metadata endpoints, and other non-public resources to an attacker with only a low-privileged account. A public exploit has been disclosed (GitHub issue #2688), meaning exploitation requires minimal technical skill beyond valid credentials.
Server-side request forgery in CordysCRM (by 1Panel-dev) up to version 1.4.1 allows low-privileged remote attackers to manipulate the mkAddress parameter in the Third Party Endpoint's SSO token service, causing the application server to issue unauthorized HTTP requests to attacker-controlled destinations. The affected component is TokenService.java within the CRM's SSO integration layer, meaning exploitation could expose internal network topology or interact with internal services unreachable from the public internet. A public proof-of-concept exploit exists; the project vendor closed the issue report without acknowledging it as a valid security vulnerability, leaving no official remediation path confirmed.
Server-side request forgery in MaxKB before 2.10.0 allows any authenticated user holding the default workspace USER role to coerce the application server into making arbitrary HTTP requests to attacker-controlled destinations via the `downloadCallbackUrl` and `download_url` parameters on ToolSerializer endpoints. An attacker can pivot through the MaxKB host to probe and extract data from internal network services - cloud metadata APIs, internal databases, adjacent microservices - that would otherwise be inaccessible from outside the network perimeter. A public proof-of-concept exists at GitHub issue #6272; this is not confirmed actively exploited (not in CISA KEV).
Stored cross-site scripting in CordysCRM (1Panel-dev, versions up to 1.4.1) allows an authenticated remote attacker to inject malicious scripts via the unvalidated Description parameter in the ModuleFormController's Save function. The payload persists to the database and executes in any victim's browser upon viewing the affected module form, enabling session hijacking, credential theft, or UI-based phishing. A publicly available proof-of-concept exists (GitHub issue #2233); no public exploitation at scale has been confirmed, and an official vendor patch is available as of v1.7.0.
Authenticated SSRF bypass in MaxKB's OSS file service URL fetch allows low-privilege users to reach internal network services by exploiting inconsistent DNS resolution between validation and request execution. MaxKB 2.8.0 and all prior versions are affected; the attacker causes the validation step to resolve a domain to a public IP, then swaps the DNS record so the actual HTTP fetch resolves to an internal address, bypassing the SSRF filter entirely. No public exploit has been identified and this CVE is not listed in CISA KEV; a vendor-released patch (2.8.1) is available.
Broken access control in MaxKB 2.8.0 and earlier exposes the OSS file service URL fetch API (`chat/api/oss/get_url`) to cross-application data access by authenticated low-privilege users who supply arbitrary `application_id` values in the URL path. Because the endpoint performs no ownership validation against the requesting session, any authenticated user can retrieve OSS file URLs scoped to applications they do not own, violating multi-tenant isolation. No public exploit code exists and the issue is not listed in CISA KEV; a vendor-released patch is available in version 2.8.1.
Server-Side Request Forgery in MaxKB before 2.9.1 allows authenticated users to pivot into internal network infrastructure by supplying arbitrary URLs to the work_flow_template import endpoint. The server fetches attacker-controlled URLs without validation or internal IP filtering, enabling reconnaissance of internal services, cloud metadata endpoints, or other resources unreachable from the public internet. The CVSS 4.0 score of 6.3 is driven primarily by high subsequent-system confidentiality impact (SC:H), reflecting the lateral reach into backend infrastructure that SSRF typically enables. No public exploit code or active exploitation has been identified at time of analysis.
MaxKB, an open-source enterprise AI assistant by 1Panel-dev, stores user passwords as unsalted MD5 hashes, exposing all user credentials to trivial offline cracking upon any database compromise. All versions prior to 2.9.1 are affected (CPE: cpe:2.3:a:1panel-dev:maxkb). The CVSS 4.0 vector (AV:L/VC:H) confirms that while local or database-level access is a prerequisite, once hashes are obtained, full credential recovery is practically guaranteed using rainbow tables or GPU-accelerated tools such as hashcat - no public exploit identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Server-side request forgery in MaxKB v2.8.0 and earlier allows authenticated low-privilege users to reach internal network services by exploiting an URL parsing inconsistency at the OSS file fetch endpoint. The discrepancy between Python's urlparse validation logic and the requests HTTP client means a crafted URL can pass security checks yet still route to internal infrastructure when executed by the server. No public exploit or KEV listing exists at time of analysis; the vendor has confirmed and patched the issue in 2.8.1.
Stored Cross-Site Scripting in MaxKB's MdRenderer component allows authenticated users to inject malicious scripts via custom <iframe_render> tags in LLM responses or Application Prologue configurations, leading to JavaScript execution in the parent window context with access to session tokens and sensitive data. MaxKB versions 2.7.1 and earlier are affected; the vulnerability is fixed in version 2.8.0. The attack requires user interaction (UI:P) but impacts all visitors to an affected application's chat interface, making it a high-impact stored XSS despite the moderate CVSS 5.1 score.
Stored Cross-Site Scripting in MaxKB 2.7.1 and below allows authenticated users to inject arbitrary JavaScript into the Application prologue field via <html_rander> tags, which the backend stores unsanitized and the frontend renders with innerHTML-equivalent mechanisms. Exploitation enables session hijacking, unauthorized workspace/application deletion, and sensitive data exposure against any visitor accessing the affected chatbot. Fixed in version 2.8.0.
MaxKB versions 2.7.1 and below allow authenticated users to spoof tool execution results by exploiting Python frame introspection to extract the wrapper's UUID from bytecode, then writing forged output directly to file descriptor 1 to bypass stdout redirection and terminate the wrapper process before legitimate output is generated, causing the service to trust the attacker-controlled response. This integrity bypass requires prior authentication and local/network access but enables attackers to manipulate AI tool results without detection. The vulnerability has been patched in version 2.8.0.
MaxKB versions 2.7.1 and below allow authenticated administrators to trigger arbitrary code execution on their own workstations through improper CSV formula sanitization in the chat export feature. When exporting chat history to Excel via the /admin/api/workspace/{workspace_id}/application/{application_id}/chat/export endpoint, formula strings (e.g., =cmd|'/c calc'!A1) are written unsanitized to the .xlsx file, enabling Dynamic Data Exchange (DDE) exploitation when the file is opened in Microsoft Excel. No public exploit code has been identified, but the vulnerability represents a high-impact attack path for administrators with legitimate export access and is a direct repeat of a previously patched flaw (CVE-2025-4546) that was incompletely remediated across the codebase.
Stored Cross-Site Scripting (XSS) via Eval Injection in MaxKB's Markdown rendering engine allows authenticated users to execute arbitrary JavaScript in other users' browsers, including administrators. MaxKB versions 2.7.1 and below are affected. The vulnerability requires user interaction (UI:P) and low privileges (PR:L) to exploit, but delivers high integrity impact (VI:H) to victim sessions. A vendor-released patch is available in version 2.8.0.
Stored Cross-Site Scripting (XSS) in MaxKB 2.7.1 and below allows authenticated users to inject malicious JavaScript through application name or icon fields, which is then executed in victims' browsers when accessing the public chat interface. The vulnerability stems from unsanitized data insertion into HTML responses by ChatHeadersMiddleware, enabling arbitrary code execution with user interaction. MaxKB 2.8.0 has released a patch to fix this issue.
Cross-site scripting (XSS) in 1Panel-dev MaxKB up to version 2.4.2 allows authenticated remote attackers to inject malicious scripts via the MdPreview component in ui/src/chat.ts, requiring user interaction to execute. Publicly available exploit code exists for this vulnerability. The vendor released patched version 2.5.0 addressing the flaw with commit 7230daa5ec3e6574b6ede83dd48a4fbc0e70b8d8.
OS command injection in 1Panel-dev MaxKB up to version 2.6.1 allows authenticated remote attackers to execute arbitrary operating system commands through manipulation of the Model Context Protocol Node's execute function in base_mcp_node.py, with publicly available exploit code and vendor-released patches available for remediation.
Stored cross-site scripting (XSS) in 1Panel-dev MaxKB up to version 2.6.1 allows authenticated remote attackers to inject malicious scripts via the Name argument in ChatHeadersMiddleware, requiring user interaction to trigger. The vulnerability has a low CVSS score (3.5) due to requiring authentication and user interaction, but XSS can lead to session hijacking or credential theft. Vendor-released patch version 2.8.0 addresses this issue.
Cross-site scripting (XSS) in 1Panel-dev MaxKB up to version 2.2.1 allows authenticated remote attackers to inject malicious scripts via the Name argument in the StaticHeadersMiddleware component of the Public Chat Interface. The vulnerability requires user interaction (UI:R) and has low confidentiality impact but enables persistent code execution in user browsers. Publicly available exploit code exists, and vendor-released patch version 2.8.0 resolves the issue.