CWE-1188: Insecure Default vulnerabilities

Some docker-compose shipped by the project exposes by default Webadmin REST API publically without proper authentication setup. Version 3.9.1 onward sets a random credential by default on unprotected webadmin endpoints to prevent this while retain convenience.

Apache OFBiz versions prior to 24.09.08 contain a vulnerability in the REST API framework's ModelApiReader parser. Due to an incorrect default value for the auth attribute in .rest.xml definitions, unauthenticated remote attackers can invoke REST API operations without valid credentials. This occurs because ModelApiReader incorrectly treats the missing auth attribute as false, allowing unauthorized access. The issue is fixed in version 24.09.08.

The activestorage gem before 8.1.4.1 for Ruby on Rails, when ImageMagick attachment processing occurs, can allow server read and write operations (e.g., reading secret_key_base) because the ImageMagick analyzer runs when a file is attached, and there is not an ImageMagick security policy to block unintended functionality.

node-opcua is an OPC UA implementation for TypeScript and Node.js. From 2.42.0 until 2.180.0, namespace-level access control configured through setDefaultRolePermissions is not honored by the runtime enforcement path for nodes without explicit per-node RolePermissions. SessionContext.getApplicableRolePermissions reads a missing or null DefaultRolePermissions metadata value instead of the configured namespace field, and the null result is treated permissively. An anonymous network client can consequently write variables with CurrentWrite access or call bound methods when an operator configured a restrictive namespace default and relied on inheritance. Servers with no declared policy, nodes with explicit per-node permissions, and correctly bound programmatic namespace metadata are outside the authorization-bypass case. This issue is fixed in version 2.180.0.

Temporal Server compiles a Worker Controller Instance module, go.temporal.io/auto-scaled-workers, into its Worker Service, and that module registers a compute provider named k8s whose function is to manage workers running in a Kubernetes cluster. The k8s provider built its Kubernetes client from the client configuration supplied in the caller's request rather than from operator configuration, and building and using that client could run a command of the caller's choosing on the Worker Service host, under the account the server process runs as. Two frontend operations reach the provider. CreateWorkerDeploymentVersion requires a namespace write role. ValidateWorkerDeploymentVersionComputeConfig is registered as a read-only namespace operation, so an authenticated caller holding only a read role in a single namespace can reach the provider through it, and that route does not require a worker deployment to already exist. Execution happens while the submitted configuration is validated, so no scaling decision, task arrival, or unusual request sequence is required. Because the Worker Service process holds the persistence credentials for every namespace in the cluster and the cluster's TLS material, the consequence reaches beyond the caller's namespace to the cluster as a whole. The provider is present in the official temporal-server binaries and container images for the affected releases. The control that keeps it unreachable is the compute provider allowlist, the dynamic configuration setting workercontroller.compute_providers.enabled. On Temporal Server 1.31.0 through 1.31.2 that allowlist does not deny by default: when the setting is unset the check is skipped and every registered compute provider is permitted, k8s included, so a stock deployment of those releases is exposed. On 1.31.3 and later 1.31 releases, and on 1.32.0 and later 1.32 releases, the allowlist denies by default, and a deployment is exposed only where k8s has been added to it. The 1.30 release line does not include the Worker Controller Instance module and is unaffected. To determine whether a deployment is affected, check the following together. The deployed Temporal Server version is in an affected range. The Worker Service is running, which it is in the default service set and therefore in a stock deployment. The effective value of workercontroller.compute_providers.enabled contains k8s, or, on 1.31.0 through 1.31.2 only, is unset; check both the global value and every namespace-constrained override, because an override can add k8s for a single namespace. And authorization is configured, meaning a real authorizer and claim mapper are in place; a deployment running with no authorizer already grants every caller unrestricted access to every namespace, so it has no namespace boundary for this to cross. Deployments that use a custom authorizer should also check whether it permits ValidateWorkerDeploymentVersionComputeConfig to callers without namespace write access. The separate per-namespace dynamic configuration setting workercontroller.enabled does not gate the affected path on any affected release.

WebDyne versions from 2.022 before 3.022 for Perl disclose application source to unauthenticated clients via the viewer in the default index page. WebDyne's wrapper scripts, such as webdyne.psgi, enable the built-in index page by default. Its source viewer returns files under the document root named in the source parameter of an HTMX request, including .psp, .pm and .pl files. A remote attacker can read the application's Perl code, including the __PERL__ blocks of .psp pages and any credentials they hold.

When a server in pgAdmin 4 had no password file, client certificate or client key configured, or the configured one could not be found, pgAdmin left the parameter out of the connection and libpq fell back to the defaults of the operating-system account running pgAdmin: ~/.pgpass, ~/.postgresql/postgresql.crt and postgresql.key, or PGPASSFILE, PGSSLCERT and PGSSLKEY. In server mode any user could therefore connect to a server with the service account's saved passwords or client certificate, and supplying only a copy of its public certificate was enough for libpq to pair it with the service account's private key. A pg_service.conf entry, or a maintenance database name read as a connection string by pg_dumpall, could bring the same files back for the utilities. The fix gives each of these parameters a value in server mode, the user's own file or otherwise a path that can never be opened, in the connection string, in the environment of the utilities and in the --dbname connection string that ranks above a service entry. Desktop mode is unchanged. This issue affects pgAdmin 4: before 9.19.

When a pgAdmin 4 connection was not meant to use a Kerberos user's delegated credentials, pgAdmin removed KRB5CCNAME from its environment, so the Kerberos library fell back to the default credential cache, or a client keytab, of the operating-system account running pgAdmin. libpq then answered any server that asked for GSSAPI authentication with that account's ticket, whatever user name the pgAdmin user gave, so in server mode any user could connect as the service account's Kerberos principal; gssencmode=disable did not prevent it. On Windows, SSPI used the service account's logon in the same way. psql was also started with pgAdmin's environment, which could hold another user's credential cache while that user was connecting. The fix points KRB5CCNAME and KRB5_CLIENT_KTNAME at a file that cannot exist except while a Kerberos-authenticated user connects with Kerberos, and gives every other connection, psql and the utilities require_auth=!gss,!sspi and gssencmode=disable, checked on the final connection string. require_auth needs libpq 16 or later. This issue affects pgAdmin 4: before 9.19.

pgAdmin 4 opens SSH tunnels with the sshtunnel library but gave it neither host_pkey_directories nor ssh_config_file, so it always loaded the unencrypted private keys in ~/.ssh of the operating-system account running pgAdmin, read that account's ~/.ssh/config (IdentityFile, User, HostName, ProxyCommand) for the tunnel host, and could use its ssh-agent. In server mode any user could therefore configure a tunnel to a host that accepts the service account's key, with no credentials of their own or with an identity file that did not exist in their storage, and reach it as that account. The fix makes tunnels in server mode use only the identity file or password the user configured: the service account's keys, configuration and agent are no longer used, and an identity file that cannot be found in the user's storage is reported instead of falling back to ~/.ssh. Desktop mode is unchanged. This issue affects pgAdmin 4: before 9.19.

CVE-2026-112255 is a vulnerability in OpenText Advanced Authentication Server versions 6.4.0.0 through 6.6.1.0 involving insecure default initialization of a resource. Specifically, the issue arises from allowing creation or recreation of Unauthenticated Endpoints without proper network restrictions, leading to excessive allocation. The vulnerability is addressed in version 6.6.2.0 by enforcing secure configuration practices that restrict endpoint creation to trusted networks.

MIME::Parser versions prior to 5.521 for Perl have an insecure default configuration that does not limit the number of message parts processed, potentially leading to memory exhaustion. The default max_parts option was set to -1, disabling any limit and allowing a parser to build an entity for every message part regardless of quantity. Version 5.521 introduces default limits of max_parts to 1000 and max_depth to 64 to mitigate this issue.

Apache Kafka brokers using SASL/OAUTHBEARER with the bundled JWKS-backed validator verify JWT signatures but do not enforce issuer and audience claim checks by default. This can allow tokens from different issuers or tokens lacking audience claims to authenticate if the JWKS endpoint serves keys for multiple issuers. From version 4.4.0, Kafka requires explicit configuration of issuer and audience checks or allows opting out. Versions from 3.1.0 up to but not including 4.4.0 are affected if these settings are not configured.

Authlib versions from 0.15 up to but not including 1.9.1 contain an authorization bypass vulnerability in the ClientConfigurationEndpoint implementations. These implementations improperly verify client permissions by only checking if the target client is editable, without confirming that the request credential belongs to that client. This flaw allows a client with any valid registration access token to read, modify, or delete other clients' registrations. Modifying redirect_uris can lead to authorization code or token interception, and deleting registrations can cause denial of service for affected clients. The vulnerability is fixed in version 1.9.1.

CVE-2026-25784 is a critical vulnerability in Hallo Welt! GmbH BlueSpice container images that allows privilege escalation. The issue arises from an insecure default initialization of the $mwsgTokenAuthenticatorServiceCIDR setting in LocalSettings.php, which disables IP restrictions when the environment variable WIKI_SERVICE_TOKEN_AUTH_ALLOWED is not set. This flaw permits any user with read access, including anonymous users on publicly readable wikis, to obtain an application token via the REST API and escalate to sysop privileges. The vulnerability affects BlueSpice versions from 5.2.3 up to but not including 5.2.7. A fix is available in version 5.2.7.

Authlib versions prior to 1.9.0 have an improper authentication vulnerability in the JWTBearerGrant implementation. The default get_audiences() method returns an empty list, causing the verify_claims() method to only check for the presence of an aud claim without verifying it matches the current authorization server. This allows an attacker with a valid assertion for another service sharing the signing key to obtain an access token improperly. The issue is fixed in version 1.9.0.

CVE-2026-114123 is a vulnerability in dynamics365ninja d365fo-mcp-server versions prior to 1.11.0 where missing authentication allows unauthenticated access to critical read-only API endpoints. The default Azure deployment sets the API key to an empty string, causing the server to accept requests without authentication. This exposes proprietary X++ source code snippets and metadata, including business logic and security role information. The issue is fixed in version 1.11.0.

Draft text for GHSA-qw47-mcm5-934w. The body below drops into the GitHub advisory description field; the metadata block maps to the form fields. Set the patched version at release; publish when the fix ships._ --- - **Ecosystem:** Maven - **Affected package:** `org.a2aproject.sdk:a2a-java-sdk-server-common` (task store / authorization) - **Affected versions:** `<= 1.2.0.Final` (and `1.2.1.Final-SNAPSHOT` on `main` prior to the fix) - **Patched version:** _(the release that carries the fix, e.g. 1.2.1.Final)_ - **CWE:** CWE-1188 (Insecure Default Initialization), CWE-862 (Missing Authorization) - **Severity:** High - **CVSS v3.1:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` (7.5, High) --- ## Details The default task store performs no authorization on task reads. `InMemoryTaskStore`'s no-arg constructor sets `authorizationProvider = null`, and `InMemoryTaskStore.get(String taskId)` is a bare map lookup with no authorization check regardless of provider: ```java public InMemoryTaskStore() { this.authorizationProvider = null; // default wiring } @Override public @Nullable Task get(String taskId) { return tasks.get(taskId); // no owner / caller check } ``` Authorization is enforced only when the application both supplies a `TaskAuthorizationProvider` *and* routes requests through `AuthorizationRequestHandlerDecorator` (via CDI), which checks ownership before delegating. A server that uses the default store, or wires `DefaultRequestHandler.builder().build()` manually, or integrates through a non-CDI stack (e.g. Spring), never reaches that check. The safe posture is therefore opt-in and the shipped default is the unsafe one. A caller can read a task created by another caller simply by knowing or guessing its id. ## Summary With the SDK's default configuration, task reads are not authorized: any caller can retrieve a task (including its status, context, message history, and artifacts) created by another caller, by supplying the task id. ## PoC Using only the real production classes wired the default way (no mocks): 1. Construct the default store: `InMemoryTaskStore store = new InMemoryTaskStore();` (no-arg constructor, so no authorization provider). 2. As one caller, save a task: `store.save(victimTask, false);` with id `victim-task-42`. 3. As a second, unrelated caller with no auth context, read it back: `store.get("victim-task-42")`. The second caller receives the first caller's task in full, with no authorization check: ``` unauthenticated get(victim-task-42) returned task owned by nobody-checked: victim-task-42 / ctx=victim-ctx ``` Verified on `main` (commit `72d220c`, JDK 21) and reproduces unchanged on `1.2.0.Final`. ## Impact Task data crosses caller boundaries with no authorization. In any multi-caller deployment built on the default wiring, one caller can enumerate and read another caller's tasks, including task status, context id, the message history, and any artifacts the task carries, which for agent workloads is frequently sensitive input and generated content. Because the insecure behaviour is the default rather than a misconfiguration, it is easy to ship unintentionally, and in the default/reference deployment the transport endpoints are served without authentication enforced, so the read is reachable by an unauthenticated caller (`PR:N`). CVSS is scored against the default configuration as shipped. ## Remediation Fail closed by default: deny task reads when no authorization provider is configured, rather than treating a missing provider as allow-all, and apply the authorization check in the store's `get` path (not only in `list` and the CDI decorator) so it holds regardless of how the handler is wired. If the current permissive default is retained for single-user/testing scenarios, emit a prominent startup warning when the server comes up with no authorization provider so it cannot be shipped by accident. ## Workarounds Until a fixed release, configure a `TaskAuthorizationProvider` and ensure requests are routed through the authorization decorator (CDI wiring), rather than relying on the default no-arg store or a manually built handler. ## References - CWE-1188: Insecure Default Initialization of Resource: https://cwe.mitre.org/data/definitions/1188.html - CWE-862: Missing Authorization: https://cwe.mitre.org/data/definitions/862.html

CVE-2026-103091 is a critical vulnerability in Google OSS Agent Mesh (SAM) versions 0.1.0-alpha.1 through 0.1.0-alpha.8. It involves missing authorization and insecure default initialization in the MCP proxy and OIDC registration flow, allowing remote attackers to self-enroll and gain full read, write, and execution access on backend services. The flaw arises because the GET /info endpoint publicly exposes OIDC configuration, and the POST /register endpoint auto-enrolls any valid OIDC token holder without claim filtering or ban checks. The default policy binds authenticated users to wildcard services and targets, enabling broad unauthorized access. The issue is fixed in version 0.1.0-alpha.9, which enforces stricter policy controls and ban checks.

FileRise versions from 3.9.0 up to but not including 3.22.0 contain a vulnerability involving the use of a hard-coded legacy compatibility key. This key can be activated in pristine manual installations lacking a persistent tokens key, allowing attackers who obtain certain encrypted account or configuration files to decrypt TOTP secrets or credentials. Docker installations are not affected due to unique persistent keys. The issue is resolved in version 3.22.0.

Epic Games Unreal Engine up to version 5.8.0 has an insecure default configuration in the LaunchURL Blueprint node, allowing all URL schemes. On Windows, this can lead to execution of local files via ShellExecuteW() when a file:/// URI is used. This vulnerability affects any Unreal Engine game that loads user-generated content with Blueprints, enabling potential command execution from malicious local or remote files. It is classified as CWE-1188 and has a high severity with a CVSS score of 7.7.