Intelligence
Explorer.

A flaw has been found in oretnom23 file-management-system-php up to 2e3c1ebe60f121e8df4fb3f544f0e9591d9a01e4. This affects the function save_files of the file admin_class.php. Executing a manipulation of the argument Upload can lead to unrestricted upload. It is possible to launch the attack remotely. The exploit has been published and may be used. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The project was informed of the problem early through an issue report but has not responded yet.

A vulnerability was detected in oretnom23 file-management-system-php up to 2e3c1ebe60f121e8df4fb3f544f0e9591d9a01e4. Affected by this issue is some unknown functionality of the file files.php of the component File Management. Performing a manipulation of the argument fid/id results in sql injection. It is possible to initiate the attack remotely. The exploit is now public and may be used. This product is using a rolling release to provide continious delivery. Therefore, no version details for affected nor updated releases are available. The project was informed of the problem early through an issue report but has not responded yet.

D365 F&O MCP Server is a Model Context Protocol server for querying Dynamics 365 Finance & Operations X++ code and metadata. Prior to version 1.11.0, the officially documented Azure one-click deployment uses infrastructure/azuredeploy.json and infrastructure/main.bicep to default the apiKey parameter to an empty string and pass it to the App Service API_KEY setting. With API_KEY unset or empty, src/middleware/apiKeyAuth.ts passes requests through without authentication, while src/index.ts binds the HTTP listener to 0.0.0.0 by default. If the deployer leaves the optional key blank and does not add separate network restrictions or upstream authentication, the resulting public App Service allows unauthenticated JSON-RPC tools/call requests to /mcp. The deployment's MCP_SERVER_MODE=read-only setting does not prevent anonymous access to read/search tools, including search, get_object_info, batch_get_info, extension_info, security_info, find_references, and find_event_handlers, exposing indexed proprietary X++ source snippets and metadata. Exposed information can include business logic, extension and event-handler wiring, security-role and privilege structure, and labels originally indexed from PackagesLocalDirectory. Deployments protected by a configured API key, effective upstream authentication, or network restrictions preventing attacker access are outside this unauthenticated exposure scenario. This issue is fixed in version 1.11.0.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. 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 who had separately gained code execution in the GPU process could supply inconsistent frame geometry and cause the main process to read out-of-bounds memory while producing captured frame images, disclosing memory or crashing the application. This issue is fixed in versions 42.11.6, 43.7.3, 44.4.3, and 45.0.0-alpha.9.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. 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, causing the requestingUrl passed to session.setPermissionRequestHandler to identify trusted content for a launch requested by untrusted content. An application that grants openExternal based on the requesting origin and allows untrusted content to open or navigate windows could therefore allow that content to launch an OS-registered external application. This issue is fixed in versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. 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. This issue is fixed in versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.5.

Slack Morphism is a client library for Slack Web/Events API/Socket Mode and Block Kit. Versions 1.0.0 through 2.27.0 expose the correct Slack request HMAC when signature verification fails. For an invalid request, `slack-morphism` computes the correct signature for the attacker-controlled timestamp and request body and stores it in `SlackEventWrongSignatureError.generated_hash`. The error's `Debug` and `Display` representations expose that value, and the default Axum listener error handler logs it at error level. An attacker who can both reach the application's Slack callback endpoint and read its application/service logs can therefore use the verifier as a chosen-message HMAC oracle. The attacker can send an arbitrary request with an invalid signature, recover the correct signature from the resulting log entry, and resend the same request within the five-minute freshness window. The second request passes Slack Morphism's signature verification and reaches the protected application callback without the attacker knowing the Slack signing secret. Version 2.28.0 patches the issue.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 42.11.9, 43.7.6, 44.5.0, and 45.0.0-alpha.13, 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 that embeds untrusted iframe content and grants pointer lock based on the requesting origin could therefore grant the permission under the top-level page's identity. Applications that deny pointerLock for untrusted embedded content are not affected. This issue is fixed in versions 42.11.9, 43.7.6, 44.5.0, and 45.0.0-alpha.13.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 42.11.1, 43.5.1, 44.1.1, and 45.0.0-alpha.4, chrome.tabs.query() returned each tab's url and title to extensions that had neither the tabs permission nor matching host permissions. An application that loaded an extension it did not fully trust through session.extensions.loadExtension could therefore allow that extension to read the URL and title of every webContents in its session. This issue is fixed in versions 42.11.1, 43.5.1, 44.1.1, and 45.0.0-alpha.4.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.6, Electron treated pages opened into a new window from links 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. An application that loads untrusted content and permits it to open new windows could therefore allow that content to make a credentialed request to another site that relies on SameSite cookies for CSRF protection. This issue is fixed in versions 42.11.3, 43.7.0, 44.3.0, and 45.0.0-alpha.6.

Incorrect authorization in the COM administration API of Progressive Robot hMailServer 6.3.4 through 6.3.6 allows an account assigned the serveradmin role with a list of domains - a credential an administrator may create meaning to confine it to those domains - to act as the whole-server administrator over COM. Administrator roles are meant to confine such a credential to the domains its list names, and the REST API did not take it for the server administrator, but the COM API's server-administrator check read the administer_server permission as the whole server whatever list the grant carried. So the credential signed in through the Control Panel, or through a script run on the server, as the server administrator of every domain: it could read and change every domain's accounts and mail, rename any domain, map a domain alias onto any, write the server's settings and secrets, and create further server-administrator accounts. The COM API's domain-administrator check, asked with no domain, likewise let an account assigned the domainadmin role with a list of domains that leaves out the account's own domain administer that domain's ordinary accounts over COM. An account holding serveradmin with no list is the server administrator by design and is unaffected, as are the help desk, auditor and custom roles.

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. A domain administrator, an account or API key given another role that manages accounts in named domains, or a full-scope API key issued for named domains could create a domain alias for any name (so that other tenants' mail for that name is diverted to an address the attacker controls, or denied), rename a domain to any name the server does not host, set a rule's bind-to-address, send-using-route or script-function action to reach one of the server's own addresses, a configured route's stored credentials or a function of the server's event script, and set the domain's relay host - which delivery then connects to with no address rule - to an address on the server's own network; and over the COM API any account could set the three rule actions on its own rules, where the script-function action runs at delivery. The authorization gate did not refuse these routes to a confined credential and the handlers were not given the caller; over COM the domain-alias save performed no authorization check at all, the domain rename required only a domain administrator, and a rule save required at most that the caller could change the rule's owner.

Not failing securely in the anti-virus attachment-stripping action of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to have a message that 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 default action deletes the message), the server keeps one text part of an infected message and replaces every attachment with a note. A message whose single part is not text - a program or an archive sent as the whole message, a message carried whole, a file declared an attachment, or an S/MIME message signed as one part, whose content the recipient's mail client opens - had no part the action could pick out, and was delivered as it arrived, with the content the scanner had found and nothing but a line in the application log to show it. Any sender can write such a message.

Insufficient preservation of the original sender in the forwarding of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to have mail they write, naming in its From an address at a domain the server hosts, delivered to other receivers as passing that domain's DMARC policy. When the server sent on a copy of mail that came from outside - an account's forward, a mail rule's forward, a Sieve redirect, a list's copy, or an alias or list expanding to an outside address - it could give the copy an SMTP identity in the organisation of the domain the copy's From names, whatever the message's origin: with the Sender Rewriting Scheme or the rewrite of the envelope sender on forwarding enabled (both off by default), an address at the forwarding domain; for a list, its bounce address; for a message with an empty envelope sender, none, under the server's own host name; and an envelope sender the message came with at a subdomain of a hosted domain was kept. Where that identity's SPF record authorises the server, other receivers' SPF check of the copy passed for a domain aligned with the From, and DMARC passed with it, although the message had not passed DMARC when the server received it. Exploitation needs a forward, redirect, alias or list that carries the hosted domain's mail to an outside address, and one of: SRS or the envelope rewrite enabled; a list whose bounce address is in the domain's organisation; an envelope sender at a subdomain whose SPF record authorises the server; or, for an empty envelope sender, an SPF record that authorises the server under its host name. The DKIM route to the same result is CVE-2026-107567.

Missing authorization in the REST metrics route of Progressive Robot hMailServer 6.2.25 through 6.3.6 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 the server's traffic counters over the last 30 days; those counters are server-wide and carry no domain, which is why the report routes already refuse the same counters to a credential confined to named domains. The metrics route was not among the routes the server's authorization gate refuses a confined credential and its handler was not given the caller, so a domain administrator, an account given another role that holds view_configuration in named domains (the auditor role given a domain list among them), or an API key issued for named domains could read the whole server's traffic totals rather than its own domains'. The disclosure is of aggregate operational counters, not of any message or account.

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 - a full-scope API key issued for those domains, or an account assigned the serveradmin role with a list of domains - to obtain the server administrator's authority. An account's admin level gives it authority, and a role assigned to it replaces that authority, which is how an administrator narrows an account whose admin level is the server administrator's. The route that takes a role away (DELETE /api/v1/role-assignments/{address}) checked only that the credential takes in what the account held at the time, not what it would hold afterwards, so such a credential could take a narrowing role away from an account in its domains whose admin level is the server administrator's, returning it to the server administrator's authority, and, having set that account's password while it held the narrower role, sign in as the server administrator.

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 - granting another domain's role every permission over its mailboxes and settings, or removing what it needs. A custom role may not hold administer_server, administer_domain or manage_roles, so the confined credential cannot make itself or another a server administrator by creating or rewriting a custom role.

Use of a less trusted source for the envelope sender in the external-account download of Progressive Robot 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. An attacker needs to know a mailbox elsewhere that an account here collects and forwards to an outside address; an account holder who adds an external account of their own can collect from a server of their own, which matters where SmtpAuthenticatedSenderCheck holds signed-in senders to their own addresses.

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, such as the recipient of a forwarded message, could have the server relay mail to the address it encodes for 21 days, and an account holder whose account forwards to an outside mailbox could obtain one for any address. SRS is off by default.

Insufficient resource pool in the ACME HTTP-01 challenge responder of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to cause a certificate issuance or renewal to fail. When the server obtains or renews a TLS certificate over ACME it runs an HTTP-01 challenge responder on port 80 for the certificate authority to read the challenge token; the responder served one connection at a time, accepting a socket, waiting up to five seconds to receive a request, answering it, and only then accepting the next. A client that connected and sent nothing held the single worker for the whole timeout, so enough idle connections during a validation keep the certificate authority's own request from being answered in time and the validation fails. Sustained across a certificate's renewals this leads to the certificate expiring, after which clients refuse the server's TLS; the mail service itself continues on its current certificate until then. No authentication is required to connect to the responder. Version 6.3.7 serves up to 64 connections at once and closes a connection past that, so that where a handful of idle connections, one after another, sufficed before, a client must keep 64 idle connections open at once throughout a validation to have the certificate authority's connection closed.

Insertion of sensitive information into a log file in the SMTP server of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a local user who can read the server's log, or anyone given a copy of it, to obtain credentials. With SMTP logging enabled, the server hid the credential of an AUTH PLAIN command only when it was sent after EHLO in one exact form, and wrote the rest of the SASL exchange as the client sent it: a PLAIN password sent before EHLO or with extra spacing, the OAuth 2.0 bearer token of AUTH XOAUTH2 and AUTH OAUTHBEARER (from 6.2.0), the SCRAM-SHA-256 client proof (from 6.2.0), which with the logged salt and iteration count allows offline password guessing, and the GSSAPI authenticator (from 6.3.2). SMTP logging is off by default; on Windows before 6.3.6 the log folder was readable by every local user.

Cross-site request forgery in the REST API of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote attacker to make an authenticated user's browser perform a state-changing request. The REST API accepts HTTP Basic authentication and answers a browser with a Basic sign-in box; a browser caches the credential once the box is answered and sends it with later requests to that origin, including a top-level form post from another site, and the server reads a request body whatever its declared content type. The cross-site protection covered only the cookie session (a header a cross-site form cannot set, and a SameSite=Strict cookie); HTTP Basic was not held to it. A page under an attacker's control, visited by a user whose browser holds a cached Basic credential for the REST API - typically an administrator who signed in through the box - could therefore cause a state-changing request such as creating a domain, an account or an API key, or changing a setting, with the victim's credential. The attacker cannot read the cross-origin response, so the forgery is blind.

The webhook platform gateway in Nous Research Hermes Agent versions builds the session chat_id as webhook:{route_name}:{delivery_id} and re-derives the authorizing route by splitting that string, so a route name containing a ":" resolves toolset authorization to a different, higher-privileged prefix route than the one authenticated, which allows a remote attacker with the target HMAC to gain that higher-privileged route's toolsets.

Improper link resolution before file access ('link following') vulnerability in Velneo vServer. This issue affects vServer: from 32.3 before 36.6 and from 37.1 before 37.2.