| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| This issue was addressed by removing additional entitlements. This issue is fixed in macOS Golden Gate 27. An app may be able to access user-sensitive data. |
| The Bookly – Online Scheduling and Appointment Booking System plugin for WordPress is vulnerable to Sensitive Information Exposure in versions up to, and including, 28.4 via the classic booking form's Details step. The endpoint bookly_render_details is registered for both wp_ajax and wp_ajax_nopriv, the module overrides csrfTokenValid() to always return true, and Bookly\Frontend\Components\Booking\InfoText::getCodes() calls UserBookingData::getCustomer() to load the persisted Customer entity keyed solely by the attacker-supplied phone (or email) with no invocation of the plugin's own customerIdentityConfirmed() predicate. When a site owner has placed the supported {client_name}, {client_email}, {client_phone}, or {client_note} placeholders into the Details step's Appearance information text, the matched customer's stored name, email, phone and internal notes are substituted into the returned HTML. This makes it possible for unauthenticated attackers who know only a registered customer's primary phone (or email) to read that customer's stored personal data. |
| Discourse is an open-source discussion platform. Prior to 2026.9.0, 2026.8.1, 2026.7.3, and 2026.1.9, sites with secure uploads enabled did not reconcile existing upload security metadata when a previously public category became read-restricted or when category permissions changed during a bulk import. Media and attachments uploaded while the category was public retained a public accessibility flag and remained reachable by anonymous users through their short upload URLs, including uploads associated with deleted topics. This issue is fixed in versions 2026.9.0, 2026.8.1, 2026.7.3, and 2026.1.9. |
| The Booking Calendar plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 11.4.3 via the wpbc_is_show_popover_in_flex_timeline() function. This makes it possible for unauthenticated attackers to extract sensitive data including names, email addresses, and phone numbers of customers who have made bookings. |
| Creating a draft release through the API returned an `assets` list that was built from a release without an ID, which matched every attachment that was not linked to a release. A user who could create a draft release in a repository therefore received the metadata (file name, UUID, upload time, size and download count) of issue and comment attachments of repositories they could not read, and of abandoned uploads. |
| Exposure of Sensitive Information to an Unauthorized Actor during job manipulation in Apache Kylin. The impact is minor unless job services are exposed to public network, which is uncommon.
This issue affects Apache Kylin: from 4.0.0 through 5.0.4.
Users are recommended to upgrade to version 5.0.5, which fixes the issue. |
| In the Linux kernel, the following vulnerability has been resolved:
dm: avoid leaking the caller's thread keyring via the table device file
The refactoring in commit a28d893eb327 ("md: port block device access to file")
accidentally causes the caller's thread keyring to be kept alive long
beyond the caller's lifetime.
As a result, "cryptsetup luksSuspend" silently fails to wipe the
LUKS volume key from memory.
In detail: "cryptsetup luksOpen" uses its supposedly ephemeral thread
keyring to pass the volume key to the kernel. dm-crypt's
crypt_set_keyring_key() copies the key material into its own
crypt_config structure and then drops its own reference to the key in
the keyring with key_put().
With this fix, restoring pre-v6.9 behavior, the copy in the thread
keyring is then promptly garbage collected, such that exactly one copy
of the volume key remains. This single copy is correctly wiped from
memory on "cryptsetup luksSuspend".
Without this fix, the thread keyring and the volume key in it remains.
This second copy is only freed on "luksClose". "luksSuspend" neither
knows about this copy nor has any way to remove it, so the key remains
recoverable from RAM after a suspend that is documented to have wiped it.
This fix should not introduce new security problems, as the code is
anyway gated by CAP_SYS_ADMIN. The device-mapper core, not the calling
task, is the legitimate owner of this long-lived file. |
| Coder from 2.26.0 before 2.34.8 contains an incorrect authorization flaw in the GET /api/v2/workspaces/{id}/acl endpoint, which checks only workspace read access and then fetches group members using an elevated system context. Authenticated users granted workspace use access can query the endpoint to harvest group members' emails, login types, status, and last-seen and creation timestamps. |
| FOSSBilling is an open source billing and client-management platform. From 0.1.0 until 0.8.7, the unauthenticated api/guest/system/template_exists endpoint permits path traversal because templateExists uses Path::join on the attacker-controlled file parameter without rejecting .. sequences or verifying that the resolved path remains inside the active theme directory. The trigger is an unauthenticated request to guest/system/template_exists containing traversal sequences in the file parameter. An attacker can submit traversal sequences in the file parameter and observe the returned boolean to determine whether arbitrary files or directories exist on the server. The oracle does not disclose file contents. This issue is fixed in version 0.8.7. |
| FOSSBilling is an open source billing and client-management platform. From 0.1.0 until 0.8.7, the unauthenticated POST /api/guest/client/create endpoint reveals whether a submitted email belongs to a registered client because guest signup returns a distinct unredacted error when the submitted email already exists. The trigger is an unauthenticated request to POST /api/guest/client/create with a target email address. An attacker can compare the guest-signup response for a target email to determine whether the email belongs to an existing FOSSBilling client. Box\Mod\Client\Api\Guest::create returns the error after Client\Service::clientAlreadyExists finds a matching record, and the API response exposes that exception message without redaction. This issue is fixed in version 0.8.7. |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: validate STALE_COOKIE cause length before reading staleness
When an ERROR chunk with a STALE_COOKIE cause is received in the
COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure
of Staleness that follows the cause header:
err = (struct sctp_errhdr *)(chunk->skb->data);
stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));
err is the first cause in the chunk, not the STALE_COOKIE cause that
caused the dispatch, and nothing guarantees the staleness field is
present. sctp_walk_errors() only requires a cause to be as long as the
4-byte header, so for a STALE_COOKIE cause of length 4 the read runs
past the cause, and for a minimal ERROR chunk past skb->tail. The value
is echoed to the peer in the Cookie Preservative of the reply INIT,
leaking uninitialized memory.
sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so
check its length there and pass it to sctp_sf_do_5_2_6_stale(), which
reads that cause instead of the first one. A STALE_COOKIE cause too
short to hold the staleness field is discarded.
The read is reachable by any peer that can drive an association into
COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket
in a user and network namespace. |
| The visibility check of Gitea user profiles was applied to GET requests only, while `POST /{username}` (follow and unfollow) required only a signed-in user. Any authenticated user could therefore obtain the full name, location, website and description of a user with a private profile from the response. The issue was fixed in 28.1.0 and disclosed with 28.2.0. |
| follow-redirects is a Node.js HTTP and HTTPS client wrapper that automatically follows redirects. From 1.16.0 until 1.16.1, escapeRegex leaves valid header-name metacharacters unescaped in sensitiveHeaders. When an application declares a sensitive header whose name contains ^ or | and follows a cross-origin or HTTPS-to-HTTP redirect, unescaped regular-expression metacharacters prevent the generated filter from matching the declared header name, and the credential header is forwarded to an attacker-controlled redirect target. This issue is fixed in version 1.16.1. |
| Improper Neutralization of Special Elements Used in a Template Engine and Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel HTTP, Netty HTTP, Undertow and Vert.x HTTP components.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The Camel HTTP producer families let an inbound message override the endpoint URI through the CamelHttpUri and CamelRestHttpUri headers, and then passed that message-supplied string through CamelContext.resolvePropertyPlaceholders() before using it. Property-placeholder resolution is a configuration-resolution facility, not a URI-parsing step: it reaches operating-system environment variables, JVM system properties, every PropertiesFunction registered on the classpath - including the secret functions - and, through camel-bean, the invocation of a no-argument method on any bean in the registry. Applying it to Exchange content therefore turned a URI string into a configuration- and bean-evaluation context. A route author opted into none of this: a plain static to("http://backend/api") was sufficient. Seven call sites were affected: HttpHelper.createURL and HttpHelper.createMethod in camel-http-common, HttpMethodHelper.createMethod in camel-http, VertxHttpHelper.resolveHttpURI in camel-vertx-http, UndertowHelper.createURL and UndertowHelper.createMethod in camel-undertow, and NettyHttpHelper.createURL in camel-netty-http. The bridgeEndpoint option did not bound the exposure: it suppresses the CamelHttpUri override in the createURL family but not in the createMethod family, so a route using the documented bridging configuration still resolved placeholders taken from the header, and CamelRestHttpUri was consumed before any bridgeEndpoint check in all four components. Only camel-http offered an opt-out, skipControlHeaders, which defaults to false. Reaching the headers did not always require header injection, because several Camel HTTP consumers populate CamelHttpUri from the request line themselves as a documented reverse-proxy feature. An unresolvable placeholder additionally produced a RuntimeExchangeException whose message echoed the URI, which distinguishes a set from an unset configuration key even where no outbound request is made. The behaviour predates the 4.x line. This advisory continues the alignment CAMEL-24282 applied to the toD and enrich dynamic-URI EIPs in 4.22.0, extending the same build-time-resolution contract to the HTTP producer components.
Users should upgrade to version 4.23.0, which fixes the issue. Users on the 4.22.x releases stream should upgrade to 4.22.1. Users on the 4.18.x releases stream should upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, strip the override headers at the trust boundary before the producer with removeHeader("CamelHttpUri") and removeHeader("CamelRestHttpUri"), or set skipControlHeaders=true on camel-http endpoints, which is the only component offering that option. Note that bridgeEndpoint=true is not a workaround: it suppresses the header override when the outbound URL is built but not when the header is re-parsed for the query string. Percent-encoding the placeholder delimiters is likewise not a mitigation for camel-netty-http, whose binding decodes the request path before the value reaches the header, so proxy or WAF rules written against the raw delimiters do not help there. As defence in depth, ensure consumers exposed to untrusted senders apply a strict inbound HeaderFilterStrategy over the Camel namespace, and resolve secrets through a vault rather than through environment variables or system properties that a placeholder can name. |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel HTTP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
Two paths handed credentials to a redirect target, which is a host chosen by the remote server rather than by the route, once followRedirects=true. OAuth2ClientConfigurer registers its interceptor with addRequestInterceptorFirst, and HttpClient runs protocol-level request interceptors inside ProtocolExec, which sits below RedirectExec in the exec chain; the interceptor therefore ran again for every redirect hop and re-attached Authorization: Bearer to whatever host the Location header named. Separately, credentials were registered against an AuthScope matching any host, so basic and digest credentials were presented to a redirect target as well. A remote endpoint - or anyone who can influence its responses - could therefore collect the bearer token or the configured credentials simply by answering with a redirect to a host it controls.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Credentials are now sent only to the authority the endpoint was configured with, and are not re-attached when a redirect crosses to another host. For deployments that cannot upgrade immediately, set followRedirects=false on endpoints that carry credentials, and handle any redirect explicitly in the route so that the destination is chosen by the route rather than by the remote server. |
| REDAXO is a PHP-based content management system. Prior to 5.21.2, rex_list::getSortColumn() in redaxo/src/core/lib/list.php accepts the sort request parameter without checking whether setColumnSortable() registered the requested column. An authenticated backend user can make prepareQuery() add an escaped but unauthorized ORDER BY identifier, allowing error-based enumeration of columns in joined tables and ordering by unselected sensitive fields such as rex_user.password. This issue is fixed in version 5.21.2. |
| A vulnerability was detected in light0011 cms c774dce31c6df0055568a8d5c53d964d99be199d/f72cf46f601efb2a0618c3814cc2f61380b38930. Affected by this vulnerability is the function file_exists of the file Public/Home/js/uploadify/check-exists.php of the component Uploadify. The manipulation of the argument filename results in file and directory information exposure. The attack may be launched remotely. The exploit is now public and may be used. The project was informed of the problem early through an issue report but has not responded yet. |
| Server-Side Request Forgery (SSRF), Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') and Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel Docling component.
This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.1.
DoclingProducer decided what a String message body meant by inspecting its prefix. A body starting with http:// or https:// was handed to Docling as a remote URL to fetch, a body starting with / or containing a backslash was read from the local filesystem, and anything else was written to a temporary file and converted as document content. The mode was chosen implicitly and no endpoint option allowed a route author to pin the component to a single interpretation, so a route that means convert whatever text arrives in the body silently became a fetcher of remote resources or a reader of local files whenever the text happened to begin with one of those prefixes. The only guard applied to the derived value was a size check, and that check was wrapped in an existence test, so a path that resolved to nothing, or to a pseudo-file reporting a size of zero, passed without being checked at all. Five call sites reached the two sinks: the CLI mode appended the value as the final positional argument of the docling subprocess, and the docling-serve mode passed it either to HttpSource for the backend to fetch or to Files.readAllBytes so that the content could be base64-encoded and uploaded. Because the exchange body is never filtered by a HeaderFilterStrategy, unlike the Camel header namespace, a sender able to place text in a message that a route forwards into a docling endpoint could reach both sinks without any opt-in from the deployment.
Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, do not route message bodies that originate outside the deployment into a docling endpoint, and pass the document through a typed body such as File, byte[] or InputStream, or through the CamelDoclingInputFilePath header, so that the body is never subject to prefix interpretation. |
| A security vulnerability has been detected in Webkul Aureus ERP up to 1.6.0. This issue affects some unknown processing of the file composer.json. Such manipulation leads to insertion of sensitive information into debugging code. The attack may be launched remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure. |
| In MISP, the event synchronization process contained a logic error in the preparation of event reports for remote push. The filtering of non-exportable tags was applied only once after the iteration over all reports, rather than to each individual report.
As a result:
- All reports except the last one in the set were pushed to the remote MISP instance with their non-exportable tags intact, effectively disclosing restricted tag information to the receiving instance.
- When the last report in the set was withheld (empty), a null report was pushed, causing the remote instance to fail saving the event.
This issue affects any MISP instance configured to push events with multiple reports to a remote server via synchronization.
Affected: <2.5.48. |
