Intelligence
Explorer.

ApostropheCMS is an open-source Node.js content management system. Prior to 1.5.5 of the ApostropheCMS Form add-on, its form submission route stages unbounded multipart uploads before form validation or authentication and lacks upload size, count, and rate limits. Repeated unauthenticated submissions can consume temporary disk storage and disrupt form handling or other host services. This issue is fixed in ApostropheCMS Form 1.5.5.

ApostropheCMS is an open-source Node.js content management system. Prior to 4.33.0, an authenticated editor with legitimate edit rights on a pre-existing ordinary page nested under a restricted parent can use the same-parent page move operation to change sibling ranks without create authorization on that parent. The non-default nesting must already exist, and the bypass is limited to sibling ordering rather than arbitrary content modification, confidentiality loss, or creation of the restricted nesting. This issue is fixed in version 4.33.0.

ApostropheCMS is an open-source Node.js content management system, and sanitize-html provides a simple HTML sanitizer with a clear API. Prior to sanitize-html 2.18.0, a non-default nonTextTags configuration that includes noscript can end its discard region early when htmlparser2 emits an implied ancestor close inside noscript. Because scripting-enabled browsers treat noscript content as raw text while the parser does not model that mode, content intended to remain inert can survive sanitization and render; the issue does not generalize to every default nonTextTags element. This issue is fixed in sanitize-html 2.18.0.

ApostropheCMS is an open-source Node.js content management system. Prior to 4.33.0, viewRole is not applied to anonymous visitors when a developer exposes user objects through a publicly rendered relationship or expressly enabled public API. Inadequately limited templates, including serialization of an entire related user object, can conditionally disclose user fields, but relationships do not automatically publish full user objects and password hashes are stored separately and are not affected. This issue is fixed in version 4.33.0.

ApostropheCMS is an open-source Node.js content management system. From 1.25.0 until 1.28.0, uploadfs Azure backend leaks account-level SAS token into every public attachment URL. When uploadfs is configured with the Azure backend and sas: true, createContainer() builds the BlobServiceClient from a URL that embeds the full SAS query string, and Azure SDK v12 derived clients inherit that query string. This issue is fixed in version 1.28.0.

ApostropheCMS is an open-source Node.js content management system, and uploadfs is its file storage library. Prior to uploadfs 1.28.0, attacker-controlled paths that reach the local backend can contain parent-directory segments that escape the configured upload directory and affect file reads, writes, and deletion on the host filesystem. Exploitability depends on an application exposing the relevant uploadfs operations to untrusted path. This issue is fixed in uploadfs 1.28.0.

ApostropheCMS is an open-source Node.js content management system. In sanitize-html 2.18.0, when an <iframe> is not allowed and disallowedTagsMode is 'discard' (the defaults), its raw-text content is re-sanitized by a recursive call to sanitizeHtml(text, options). The recursion has no bound and starts each nested call with a fresh state. This vulnerability is fixed in 2.18.1.

ApostropheCMS is an open-source Node.js content management system. Prior to 3.7.1 of the import-export module and 4.34.0 of core ApostropheCMS, an editor who can import an enabled content type but lacks its stronger publication role can cause import write helpers to create, replace, or remove published variants without the normal publish permission and lifecycle checks. This issue is fixed in import-export 3.7.1 and ApostropheCMS 4.34.0.

ApostropheCMS is an open-source Node.js content management system. Prior to 3.7.1 of the import-export module, the API endpoint POST /api/v1/@apostrophecms/import-export/clean-export in @apostrophecms/import-export lacks authentication and authorization checks. Any client—including unauthenticated anonymous users who have obtained the standard CSRF cookie from visiting the site—can directly invoke this route and trigger the underlying self.cleanExport(req) method. This issue is fixed in version 3.7.1.

A flaw has been found in aaPanel up to 8.25.0. Impacted is the function send_file of the file BTPanel/routes/v2.py of the component Download Endpoint. Executing a manipulation of the argument filename can lead to path traversal. The attack can be executed remotely. The exploit has been published and may be used. The vendor confirms: "The reported RCE and LFI vulnerabilities require authentication."

ApostropheCMS is an open-source Node.js content management system. Prior to 4.34.0, a project-defined free-form widget style field can carry an editor-controlled quote into an inline style attribute because the wrapper serializer does not apply HTML-attribute encoding. The quote can terminate the style attribute and inject executable attributes when published content, or an affected draft viewed by a higher-privileged user, is rendered. This issue is fixed in version 4.34.0.

ApostropheCMS is an open-source Node.js content management system. Prior to 4.34.0, the getOne REST endpoint for pages does not apply viewRole type-level restrictions or viewPermission field-level redaction. An editor-level user who knows a document _id can read the full content of admin-only pages and their privileged fields, while the getAll endpoint correctly enforces both restrictions. This issue is fixed in version 4.34.0.

The Cortex-A7 MMU Modules port validates a caller-supplied buffer by translating **one address** — the first byte. The common Module Manager hands its range check the module instance, the start address and the complete byte size; the Cortex-A7 implementation discarded the instance and the size and asked the MMU a single question about the start. A memory-protected module therefore passed any range whose first byte was user-readable, however far the rest of it reached. Privileged dispatch code then read or wrote the whole range. Because every protected-module dispatcher that consumes a buffer or an extra-parameter array goes through this one macro, the defect is not in any individual service: it is in the primitive all of them rely on.

One logical thread of a user-mode ThreadX module costs the Module Manager's shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread's system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module's allocation list. The Module Manager's thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop — every state transition valid, every service returning `TX_SUCCESS` — removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system. Vulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`.

A ThreadX module chooses `object_size` when it calls `txm_module_object_allocate`. The Module Manager adds its own 16-byte private header to that size and asked the object pool for the result **without checking the addition**. A size near the top of a `ULONG` wrapped, the pool served a block far smaller than the header, and the manager then wrote the header past the end of it and into the neighbouring byte-pool block.

The Module Manager's block-pool create dispatcher proved that two `ALIGN_TYPE` words of the extra-parameter array a memory-protected module supplies lay inside the module's data, and then used indices 0 through 3 of that array. One of the two unproved words is read by the dispatcher's own buffer check, which takes index 1 as the pool start and index 2 as the length to range-check it over. So the out-of-bounds read is performed by the validation code itself, before the kernel service is reached, and the size the caller's pool start is then validated against is a word the manager has not proved the module owns. The other unproved word is read when the service's argument list is built. Vulnerable function: `_txm_module_manager_tx_block_pool_create_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`.

A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with `txm_module_object_deallocate`. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation.

The Module Manager's object lookup validated one byte of a memory-protected module's search name and then walked as much of it as the module declared, in privileged mode, with the kernel's preemption count raised. Both lookup dispatchers are affected: the recommended `txm_module_object_pointer_get_extended` is handed a length and does not use it to bound the buffer, and the deprecated `txm_module_object_pointer_get` supplies the largest value a `UINT` can hold, so it removes the bound rather than lacking one. A module can make the walk unbounded without knowing anything about the memory it reaches, and where the walk reaches memory a privileged read cannot take, the resulting fault leaves the kernel unable to preempt for the rest of the system's life. Vulnerable functions: `_txm_module_manager_txm_module_object_pointer_get_dispatch`, `_txm_module_manager_txm_module_object_pointer_get_extended_dispatch` (both in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`) and `_txm_module_manager_object_name_compare` (`common_modules/module_manager/src/txm_module_manager_util.c`).

A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one question about the pointer: does the object lie outside the module's own code and data. That is the policy for *using* an object, and using an object a module does not own is supported and intended — `txm_module_object_pointer_get_extended` searches the system's created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a shared queue, take a shared semaphore or get a shared mutex. Destroying one of those is not sharing it. A module could name any object it had a pointer to and have the privileged dispatcher delete it.

The Web add-on's HTTP server dereferences and releases an uninitialized pointer when it detects a `Content-Length` underflow while processing a `PUT` request. The condition is reachable by an unauthenticated remote client with a single malformed request.

The X.509 parser in NetX Secure accepts an RSA public key of any size, but every signature-verification path decrypts into fixed-size buffers dimensioned for the `NX_CRYPTO_MAX_RSA_MODULUS_SIZE` default of 4096 bits. A certificate carrying a larger modulus drives an out-of-bounds write past a file-scope static during ordinary certificate-chain verification. It is reachable pre-authentication. The issuer used for the crypto operation is looked up in the remote, peer-supplied store before the trusted store, so the attacker supplies the oversized key themselves as an intermediate in the chain they present. It triggers on a TLS or DTLS client verifying a malicious server's chain, and on a server performing client-certificate authentication.

The Web add-on's HTTP server searches the entire request packet for header fields instead of stopping at the end of the header section. A header field name placed in the request body is therefore reported to the server as though it were a header, which lets a client control request framing decisions it should not be able to reach.

The TLS 1.3 Certificate-message parser in NetX Secure decrements the message length to skip a context byte without first establishing that the message has a byte to skip. A zero-length Certificate message therefore wraps the unsigned length to `0xFFFFFFFF`, which makes the bounds check that follows vacuous and sends the parser reading past the session packet buffer. The trigger is a four-byte handshake header and requires no cryptographic validity. It is reachable pre-authentication.

A missing bounds check in the TLS 1.3 Certificate-message parser of NetX Secure lets a malicious TLS 1.3 server trigger an unsigned-integer underflow and a subsequent heap out-of-bounds read in any peer that processes a remote Certificate message. It is reachable pre-authentication, during the normal handshake, before certificate verification completes.