Undercode Platform Authentication Bypass Vulnerability

Undercode Platform, Multiple Authentication Bypasses, No CVE (Critical) How the mentioned vulnerabilities work (technical details): The platform runs in "authenticated" mode but fails to enforce auth on several API endpoints due to missing middleware checks. Each endpoint handler receives `actor: { type: "none" }` and proceeds without rejection. 1. GET /api/heartbeat-runs/:runId/issues – No `assertCompanyAccess` call. An attacker with a valid run UUID (leaked via logs, error messages, or brute-force) can retrieve heartbeat run issues....

MinIO, Authentication Bypass, No CVE (Critical) The vulnerability exists in MinIO’s handling of STREAMING-UNSIGNED-PAYLOAD-TRAILER requests. When processing PutObject or PutObjectPart calls, the function newUnsignedV4ChunkedReader receives a boolean signature gate that depends only on whether the Authorization HTTP header is present. Simultaneously, isPutActionAllowed extracts credentials from either the Authorization header or the X-Amz-Credential query parameter, trusting whichever it finds. An attacker omits the Authorization header entirely and places a valid access key (e.g., minioadmin) inside X-Amz-Credential in the query string....

MinIO, Authentication Bypass, No CVE (Critical) The vulnerability exists in MinIO’s handling of STREAMING-UNSIGNED-PAYLOAD-TRAILER requests. When processing PutObject or PutObjectPart calls, the function newUnsignedV4ChunkedReader receives a boolean signature gate that depends only on whether the Authorization HTTP header is present. Simultaneously, isPutActionAllowed extracts credentials from either the Authorization header or the X-Amz-Credential query parameter, trusting whichever it finds. An attacker omits the Authorization header entirely and places a valid access key (e.g., minioadmin) inside X-Amz-Credential in the query string....

"Cisco has suffered a cyberattack after threat actors used stolen credentials from the recent Trivy supply chain attack to breach its internal development environment and steal source code belonging to the company and its customers." 𝗧𝗵𝗮𝘁 𝗶𝘀 𝘁𝗵𝗲 𝗵𝗲𝗮𝗱𝗹𝗶𝗻𝗲. But underneath it is a story I have not seen anyone talking about. 𝗛𝗢𝗪 𝗗𝗜𝗗 𝗦𝗢 𝗠𝗔𝗡𝗬 𝗚𝗜𝗧𝗛𝗨𝗕 𝗥𝗘𝗣𝗢𝗦 𝗥𝗨𝗡 𝗧𝗛𝗘 𝗖𝗢𝗠𝗣𝗥𝗢𝗠𝗜𝗦𝗘𝗗 𝗧𝗥𝗜𝗩𝗬 𝗦𝗢 𝗙𝗔𝗦𝗧? The most likely answer seems to be 𝗗𝗲𝗽𝗲𝗻𝗱𝗮𝗯𝗼𝘁, or similar dependency tracking tools. But wait. 𝘐𝘴𝘯'𝘵 𝘥𝘦𝘱𝘦𝘯𝘥𝘦𝘯𝘤𝘺 𝘵𝘳𝘢𝘤𝘬𝘪𝘯𝘨 𝘴𝘶𝘱𝘱𝘰𝘴𝘦𝘥 𝘵𝘰 𝘩𝘦𝘭𝘱 𝘱𝘳𝘰𝘵𝘦𝘤𝘵 𝘶𝘴 𝘣𝘺 𝘤𝘩𝘦𝘤𝘬𝘪𝘯𝘨 𝘸𝘩𝘦𝘵𝘩𝘦𝘳 𝘵𝘩𝘦 𝘯𝘦𝘸 𝘤𝘰𝘥𝘦 𝘱𝘢𝘴𝘴𝘦𝘴 𝘊𝘐 𝘢𝘯𝘥 𝘸𝘩𝘦𝘵𝘩𝘦𝘳 𝘢𝘯𝘺𝘵𝘩𝘪𝘯𝘨 𝘭𝘰𝘰𝘬𝘴 𝘸𝘳𝘰𝘯𝘨? That is the theory. Here is the reality:  1. Publish malicious package.  2. Dependency tracker raises PR with the update.  3. CI runs on the PR.  4. Code builds. And "build" has to be assumed to also mean code execution. A lot of libraries have build hooks or automation that runs code. Tools like Trivy are even more explicit: they are being run on purpose.  5. 𝗬𝗼𝘂 𝗮𝗿𝗲 𝗮𝗹𝗿𝗲𝗮𝗱𝘆 𝗼𝘄𝗻𝗲𝗱. Anything that can be exfiltrated is, and the follow-on attacks may already be underway while CI is still running.  6. CI keeps going to the end and may even pass, because this is a zero day and not yet in any CVE database. 𝗜𝗳 𝘁𝗵𝗮𝘁 𝗱𝗼𝗲𝘀 𝗻𝗼𝘁 𝗺𝗮𝗸𝗲 𝘆𝗼𝘂 𝘂𝗻𝗰𝗼𝗺𝗳𝗼𝗿𝘁𝗮𝗯𝗹𝗲, 𝗶𝘁 𝘀𝗵𝗼𝘂𝗹𝗱. Automated PRs that trigger CI can inject untrusted code directly into trusted environments. Did you get hit by Trivy, or by any other dependency injection attack? Did it stem from a PR that was raised automatically and then executed in CI? Does anyone think this won't happen again?

CVE-2026-1470 exposed a critical truth: most n8n instances have security issues that go beyond any single patch. After 300+ workflow audits, WotAI has published the seven-point security checklist we use internally. It covers: --> Credential exposure (hardcoded keys in nodes) --> Webhook authentication gaps --> Expression injection vectors --> Overprivileged credential scoping --> Error handling data leakage --> Execution data retention policies --> Network exposure and access controls Each section includes what to look for, how to check, and how to fix it. The full audit takes about an hour for a typical n8n instance. https://lnkd.in/ggfewufn For workflows with too many issues to patch, WotAI Flow generates clean, validated n8n JSON from scratch – start with a secure foundation instead of retrofitting one.

Seven vulnerabilities have been patched with the latest OpenSSL updates, including a flaw that can allow an attacker to obtain sensitive data. The data leakage issue, tracked as CVE-2026-31790 and rated ‘moderate severity’, affects applications that use RSASVE key encapsulation to establish a secret encryption key. The problem is that OpenSSL sometimes fails to properly verify that the encryption succeeded, yet may still return a ‘success’ message, exposing data from an uninitialized memory buffer to the attacker.  “The uninitialized buffer might contain sensitive data from the previous execution of the application process, which leads to sensitive data leakage to an attacker,” OpenSSL developers explained in an advisory. The security hole affects versions 3.6, 3.5, 3.4, 3.3, and 3.0. OpenSSL 1.0.2 and 1.1.1 are not impacted. The remaining vulnerabilities have all been classified as ‘low severity’. A majority can be exploited to crash the application and cause a DoS condition.  https://lnkd.in/dKzdstbd

Authentication and authorization are standard in modern systems.  But we often forget about one thing:   replay attacks. --- A request can be: - authenticated   - authorized …and still dangerous. Because it can be captured and sent again. --- Replay attacks matter when API has side effects: payments, orders, actions. If repeating the same request causes damage → there is a problem. --- There are 3 common ways to deal with it: 1. Idempotent APIs   → same request = same result 2. Idempotency keys   → process request only once 3. Request signing (HMAC + timestamp + nonce)   → ensures authenticity and prevents replay --- Small demo that demonstrates an attack together with a fix: 👉 https://lnkd.in/dgWHNeMK --- Security is not only: “who is calling” It’s also: “should this request be accepted again?”

You don’t need to hack a company directly anymore. Attackers just need to compromise what organizations already trust. I was recently made aware of the Axios supply chain incident through an industry professional, and from an investigation standpoint, it highlights a much deeper issue. During a short window, a malicious version of Axios was published to the npm registry. On the surface, the exposure appeared limited. In reality, the potential impact is much broader due to how modern systems automatically install and update dependencies. What makes this incident serious is the hidden exposure: • Systems could be compromised without directly using Axios • CI/CD pipelines such as GitHub Actions or Jenkins may have pulled the malicious version automatically • Identical environments could produce different results depending on timing This is not just a technical issue. It affects business operations, risk management, and trust across entire organizations. For executives, managers, and non-technical teams, this is important to understand: Your organization can be exposed without being directly targeted. This raises critical questions: • Can your build process change without your knowledge? • Do you fully trust your third-party dependencies? • Are your controls strong enough to detect a compromise that only exists for a few hours? Appreciate the industry insight shared with me on this especially as more discussion emerges around how far reaching this type of breach can be.

Exploitation of Critical Fortinet FortiClient EMS Flaw Begins The SQL injection vulnerability allows unauthenticated attackers to execute arbitrary code remotely, via crafted HTTP requests.

The penetration tester found your forgotten subdomain in 11 minutes. Your team had not touched it in three years. It was still running an unpatched version of Apache Struts. In 2017, Equifax lost 147 million records through CVE-2017-5638, an Apache Struts vulnerability that had a patch available for two months before the breach. The vulnerable server sat in a corner of their infrastructure that no one maintained. Your internal vulnerability scanner audits the assets you know about. EASM tools like Censys, Shodan, and SecurityTrails audit what the internet sees when it looks at your organization. Attackers work the second list. Certificate transparency logs expose every subdomain your organization has ever issued a certificate for, including the dev environments, staging servers, and proof-of-concept demos that never got decommissioned. A test server on a subdomain registered by an engineer who left two years ago is still your attack surface. Shadow IT compounds the problem. SaaS integrations provisioned by individual departments, cloud instances spun up outside the approval process, and API endpoints published without security review all expand the external footprint without updating the asset inventory. Continuous discovery followed by ownership assignment closes the gap. Every external-facing asset needs a human name next to it. No owner means no patching, no monitoring, and no accountability when the pen tester finds it in 11 minutes. When your organization last ran an external asset discovery, who owned the list of what was found? #CyberSecurity #AttackSurface #EASM #NetworkSecurity #VulnerabilityManagement #PenTest #SecurityArchitecture #ConvergedDefense #ShadowIT