CVE Vulnerability Catalog

D365 F&O MCP Server before 1.11.0 defaults the apiKey parameter to an empty string in the official Azure deployment template. With an empty key, authentication middleware passes requests through and the server binds to 0.0.0.0, allowing unauthenticated JSON-RPC tool access and exposure of indexed X++ source snippets and metadata.

In Electron prior to versions 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9, frame data received from the GPU process for webContents.beginFrameSubscription was not fully validated by the main process. An attacker with code execution in the GPU process could supply inconsistent frame geometry and cause the main process to read out-of-bounds memory, disclosing memory or crashing the application.

In Electron prior to versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5, requests to open external protocol URLs could be attributed to a document other than the one that initiated them. This caused the requestingUrl passed to session.setPermissionRequestHandler to identify trusted content for a launch requested by untrusted content.

Electron is a framework for writing cross-platform desktop applications. Prior to versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5, hid and usb permission checks made from an iframe caused setPermissionCheckHandler to receive the top-level frame's origin and details instead of the requesting frame's. An application that delegated hid or usb to a cross-origin untrusted iframe and allowed device access with origin-based logic could therefore grant that embedded frame access intended for the top-level page.

Slack Morphism client library versions 1.0.0 through 2.27.0 expose the correct Slack request HMAC when signature verification fails. For an invalid request, the library computes the correct signature for the attacker-controlled timestamp and body and stores it in SlackEventWrongSignatureError.generated_hash, which the default Axum error handler logs. An attacker who can reach the callback endpoint and read logs can use the verifier as an HMAC oracle and resend the request with a valid signature within the five-minute window.

In the Electron framework, pointerLock permission requests from some cross-origin iframes caused session.setPermissionRequestHandler() to receive the top-level frame's requestingUrl and isMainFrame values instead of those of the requesting frame. An application embedding untrusted iframe content and granting pointer lock based on the requesting origin could grant the permission under the top-level page's identity. This is fixed in versions 42.11.9, 43.7.6, 44.5.0, and 45.0.0-alpha.13.

In the Electron framework, chrome.tabs.query() returned each tab's URL and title to extensions that lacked both the tabs permission and matching host permissions. An application loading an untrusted extension via session.extensions.loadExtension could allow it to read the URL and title of every webContents in its session. This is fixed in versions 42.11.1, 43.5.1, 44.1.1, and 45.0.0-alpha.4.

In Electron prior to versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.6, pages opened into a new window from links were treated as application-initiated navigations instead of preserving the page containing the link as the initiator. The resulting top-level request could be classified as same-site, causing SameSite=Strict cookies to be sent and Sec-Fetch-Site not to identify the initiating page.

Incorrect authorization in the COM administration API of hMailServer 6.3.4 through 6.3.6 allows an account with the serveradmin role limited to a list of domains to act as the whole-server administrator over COM. Such an account can read and change every domain's accounts and mail, rename domains, map aliases, modify server settings and secrets, and create further server-administrator accounts.

Missing authorization in the REST and COM administration APIs of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote authenticated user whose credential is confined to named domains to change mail routing and domain configuration beyond those domains on a multi-tenant server. This includes creating a domain alias for any name, renaming a domain, setting rule actions (bind-to-address, send-using-route, script-function), and setting the domain's relay host to an address on the server's own network.

In hMailServer 6.0.0 through 6.3.6, the anti-virus attachment-stripping action does not fail securely, allowing a remote unauthenticated attacker to have a message the server's virus scanner found infected delivered to the recipient's mailbox unchanged. With virus scanning enabled and its action set to remove attachments and deliver the text, the server keeps one text part and replaces every attachment with a note. A message whose single part is not text has no part the action could pick out and is delivered as it arrived.

A vulnerability in hMailServer versions 6.0.0 through 6.3.6 insufficiently preserves the original sender when forwarding mail. A remote unauthenticated attacker can send a message with a From address in a hosted domain, and the server will forward it so that it passes SPF and DMARC checks for that domain at other receivers, even though the message did not originally pass DMARC.

In hMailServer versions 6.2.25 through 6.3.6, missing authorization in the REST metrics route allows a remote authenticated user whose credential is confined to named domains to read the server-wide traffic history. GET /api/v1/metrics/history returns server-wide traffic counters over the last 30 days, which carry no domain information.

Incorrect authorization in the REST administration API of Progressive Robot hMailServer 6.3.4 through 6.3.6 allows a remote authenticated user whose credential holds the manage_roles permission in named domains to obtain the server administrator's authority. The DELETE /api/v1/role-assignments/{address} route checked only the credential's current authority, not the resulting authority, so such a credential could remove a narrowing role from a server-administrator-level account and then sign in as the server administrator after setting its password.

Missing authorization in the REST role-management routes of Progressive Robot hMailServer 6.3.4 through 6.3.6 allows a remote authenticated user whose credential is confined to named domains to modify a custom role that accounts in other domains hold, and to create custom roles and delete any that no account holds. The routes that create, update and delete a custom role require the manage_roles permission, which only the serveradmin role holds; but a full-scope API key issued for named domains, and serveradmin assigned with a domain list, are serveradmin confined to those domains and hold manage_roles. The server's authorization gate did not refuse the three role routes to a confined credential and the route named no domain, so a credential issued to one tenant could raise or lower the permissions of a custom role assigned across other tenants.

Use of a less trusted source for the envelope sender in the external-account download of hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to have mail they write in the name of a domain the server hosts sent on by the server with an envelope sender at that domain, so that it passes the domain's SPF and DMARC at other receivers. A message the server downloads from an external POP3 or IMAP account has no SMTP envelope of its own, and the server took the address in its From header as its envelope sender, whatever that address was. A forward or redirect of the downloaded message to an outside address then left with that address as its envelope sender, which the Sender Rewriting Scheme leaves alone for a hosted domain, so that the receiver's SPF check passed for the forged domain, aligned even under strict alignment, with no non-default setting, host name record or DMARC policy needed.

Incorrect authorization in the Sender Rewriting Scheme (SRS) of Progressive Robot hMailServer 6.2.1 through 6.3.6 allows a remote attacker to relay mail through the server to outside addresses. With SRS enabled, the server rewrites the envelope sender of mail it forwards to a signed SRS address at the forwarding domain, and passes a bounce to that address back to the original sender; but it took every message to a valid SRS address, whatever its sender, as delivery to a local recipient, so the relay rules and the SMTP authentication they require were not applied, and the message was delivered to the outside address the SRS address encodes. Anyone holding a valid SRS address of the server could have the server relay mail to the address it encodes for 21 days.

In hMailServer 6.0.0 through 6.3.6, the ACME HTTP-01 challenge responder serves only one connection at a time and waits up to five seconds for a request. A remote unauthenticated attacker can hold idle connections open, preventing the certificate authority's validation request from being answered and causing certificate issuance or renewal to fail.

The SMTP server in hMailServer 6.0.0 through 6.3.6 logs credentials that should be hidden, including AUTH PLAIN passwords in certain forms, OAuth 2.0 bearer tokens (XOAUTH2, OAUTHBEARER), the SCRAM-SHA-256 client proof, and the GSSAPI authenticator. A local user able to read the logs, or anyone with a copy, can obtain credentials.

A CSRF vulnerability exists in the REST API of hMailServer 6.0.0 through 6.3.6 because cross-site protection covers only the cookie session, not HTTP Basic authentication. A browser holding cached Basic credentials can be tricked into performing a state-changing request (e.g., creating a domain, account, or API key) from an attacker-controlled site.