[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cve-CVE-2026-64638":3,"landing-trending":43,"landing-articles":112},{"id":4,"cve_id":5,"summary":6,"published":7,"cvss_data":8,"is_remote":18,"cwes":19,"cpes":21,"technologies":22,"references":23,"score":26,"epss_score":27,"epss_percentile":28,"is_kev":29,"cisa_kev_date_added":30,"cisa_kev_due_date":30,"cisa_ssvc":31,"exploits":41},373178,"CVE-2026-64638","WordPress is vulnerable to a pre-auth reflected XSS vulnerability on the login screen.\r\n\r\nVia a specially crafted malicious third-party website hosted by an attacker, it is possible for this to be escalated to an RCE vulnerability with conditions outside of the attackers control. This requires successful social engineering of and explicit interaction by the target victim.\r\n\r\nThis issue affects all versions of WordPress. Version 7.0.3 has been released, containing a fix for the vulnerability, and as a courtesy to users on older branches the fix has been backported to all branches back to 4.7.\r\n\r\nDiscovered and responsibly disclosed by [the team at pwn.ai](https:\u002F\u002Fpwn.ai\u002F).","2026-08-07T18:17:00Z",{"cvss_v4.0":9},{"Safety":10,"version":11,"Recovery":10,"baseScore":12,"Automatable":10,"attackVector":13,"baseSeverity":14,"valueDensity":10,"vectorString":15,"exploitMaturity":10,"providerUrgency":10,"userInteraction":16,"attackComplexity":14,"attackRequirements":17,"privilegesRequired":17,"subIntegrityImpact":14,"vulnIntegrityImpact":14,"integrityRequirement":10,"modifiedAttackVector":10,"subAvailabilityImpact":14,"vulnAvailabilityImpact":14,"availabilityRequirement":10,"modifiedUserInteraction":10,"modifiedAttackComplexity":10,"subConfidentialityImpact":14,"vulnConfidentialityImpact":14,"confidentialityRequirement":10,"modifiedAttackRequirements":10,"modifiedPrivilegesRequired":10,"modifiedSubIntegrityImpact":10,"modifiedVulnIntegrityImpact":10,"vulnerabilityResponseEffort":10,"modifiedSubAvailabilityImpact":10,"modifiedVulnAvailabilityImpact":10,"modifiedSubConfidentialityImpact":10,"modifiedVulnConfidentialityImpact":10},"NOT_DEFINED","4.0",8.9,"NETWORK","HIGH","CVSS:4.0\u002FAV:N\u002FAC:H\u002FAT:N\u002FPR:N\u002FUI:A\u002FVC:H\u002FVI:H\u002FVA:H\u002FSC:H\u002FSI:H\u002FSA:H\u002FE:X\u002FCR:X\u002FIR:X\u002FAR:X\u002FMAV:X\u002FMAC:X\u002FMAT:X\u002FMPR:X\u002FMUI:X\u002FMVC:X\u002FMVI:X\u002FMVA:X\u002FMSC:X\u002FMSI:X\u002FMSA:X\u002FS:X\u002FAU:X\u002FR:X\u002FV:X\u002FRE:X\u002FU:X","ACTIVE","NONE",true,[20],"CWE-79",[],[],[24,25],"https:\u002F\u002Fhackerone.com\u002Freports\u002F3877102","https:\u002F\u002Fwordpress.org\u002Fnews\u002F2026\u002F08\u002Fwordpress-7-0-3-release\u002F",0.8,0.00766,0.5215,false,null,{"timestamp":32,"automatable":33,"tech_impact":34,"exploitation":35,"cisa_decision":36,"cisa_remediation_timeline":40},"2026-08-07T18:26:27.756856Z","no","total","none",{"vector":37,"decision":38,"priority":39},"CISAv1\u002FE:N\u002FA:N\u002FT:T\u002FM:H\u002F2026-08-12T14:02:15.413485\u002F","track_star","medium","14D",[42],{"link":24},{"count":44,"next":45,"previous":30,"results":46},152,"http:\u002F\u002Fweb:8606\u002Fapi\u002Ftrending_attacks\u002F?page=2&sorted_by=-published_at",[47,54,63,70,78,85,93,96,101,105],{"id":44,"title":48,"summary":49,"published_at":50,"severity":51,"vendor":52,"products":53},"Multiple vulnerabilities in n8n - Code Execution via Repo-Local Git Config & Path Traversal to RCE & JS Task Runner Sandbox Escape to RCE","n8n is an open-source, fair-code workflow automation platform that lets users connect apps, APIs, and services through a visual node-based editor to build automated workflows, with self-hosted and cloud deployment options.\r\n\r\nGHSA-m87g-qr43-ccvc — Code execution in the n8n Git node via unchecked repository-local git configuration\r\n\r\nThe n8n Git node executed certain values from a repository's local git configuration without neutralizing them. When such a value was present in a repository's configuration, any subsequent Git node operation against that repository ran it in the context of the n8n process user, resulting in remote code execution. The flaw was not reachable through the Git node's own configuration controls, which already restrict which keys can be set directly; exploitation therefore required a separate file-write vulnerability elsewhere to plant the malicious value first. Rated High (CVSS 7.7). Affected: \u003C 1.123.69, \u003C 2.33.4, \u003C 2.34.1. Note that the advisory text and metadata disagree on the exact fixed versions — align on the higher bounds (1.123.69 \u002F 2.33.4 \u002F 2.34.1) to be safe.\r\n\r\nGHSA-6h4x-896x-fw5m — RCE in the n8n main process via path traversal in MCP node-schema loading\r\n\r\nThe @n8n\u002Fworkflow-sdk node-schema loader built a node's schema module path directly from the attacker-supplied node-type string, without filtering path-traversal sequences. An authenticated user holding global:member privileges could reference arbitrary files through directory traversal, leading to code execution inside the n8n main process. This issue affects the 2.x branch only. Rated High (CVSS 8.7), the most severe of the three. Affected: \u003C 2.33.4, \u003C 2.34.1.\r\n\r\nGHSA-m3hg-p5r9-fg9h — JavaScript task runner VM sandbox escape via EventEmitter prototype pollution leading to RCE\r\n\r\nThe JavaScript task runner's prototype-freezing routine covered globalThis functions but missed internal module constructors such as EventEmitter. An authenticated user with Code node access could exploit this gap to run arbitrary commands inside the runner container. Because the polluted prototype is a single process-wide object, the corruption persisted across every other tenant's Code node execution subsequently scheduled on that shared runner (though not on the host). On v1.x instances that had not enabled task runners, Code node JavaScript executes directly in the main n8n process, where the impact of a comparable escape could be significantly higher. Rated High (CVSS 7.2). Affected: \u003C 1.123.69, \u003C 2.33.4, \u003C 2.34.1.","2026-08-12T09:00:17.505396Z",3,"n8n",[52],{"id":55,"title":56,"summary":57,"published_at":58,"severity":59,"vendor":60,"products":61},151,"WordPress ARVE Plugin — Hardcoded Backdoor Auth Bypass to Admin","Product Overview\r\n\r\nThe Advanced Responsive Video Embedder (ARVE) is a popular WordPress plugin designed to seamlessly embed videos from multiple hosting platforms—such as YouTube and Vimeo—making them fully responsive across all device screen sizes.\r\n\r\nCVE-2026-18072\r\n\r\nCritical supply-chain vulnerability discovered in version 10.8.7 of the ARVE plugin, where a malicious backdoor was introduced via a compromised developer account. The flaw intercepts global incoming HTTP requests through the WordPress init hook, allowing unauthenticated attackers to execute arbitrary code or gain full administrative control over the website by sending specific parameters.\r\n\r\nUnauthenticated Detection Method\r\n\r\nTo detect this plugin remotely without authentication, look for specific footprints left in the web application's public source code. The most reliable passive method involves checking the HTML source of pages for injected CSS\u002FJS assets or structural wrapper classes containing wp-content\u002Fplugins\u002Fadvanced-responsive-video-embedder or arve-embed-container. Active detection can also be achieved by directly querying the plugin's readme.txt file via automated scanners like Nuclei or cURL to extract the exact installed version.","2026-08-11T07:44:11.441917Z",4,"",[62],"advanced-responsive-video-embedder (WordPress plugin)",{"id":64,"title":65,"summary":66,"published_at":67,"severity":59,"vendor":68,"products":69},150,"Traefik Auth Middleware - Identity Header Spoofing via Underscore Variants","Traefik is a widely used open-source HTTP reverse proxy and load balancer that sits in front of web applications, routing incoming requests and often enforcing authentication before traffic reaches the backend. Its BasicAuth, DigestAuth, and ForwardAuth middlewares are meant to verify who a request is coming from and pass a trusted identity to the services behind it.\r\n\r\nCVE-2026-54763\r\n\r\n Authentication-spoofing flaw that lets an attacker forge the identity or authorization information Traefik passes to backend services. To protect against spoofing, Traefik's auth middlewares strip attacker-supplied identity headers before writing their own trusted value — but they only strip the standard dashed form of the header name and miss the underscore-variant spelling, which many backends treat as identical. An attacker who can reach a protected route can inject an underscore-variant header that survives Traefik's stripping and reaches the backend — either alongside, or on the unauthenticated ForwardAuth response path instead of, the value Traefik intended to set — allowing them to impersonate another user or elevate their authorization. Rooted in inconsistent handling of header-name casing and formatting (CWE-178, CWE-290, CWE-345), it can lead to unauthorized access to protected routes and backend data wherever Traefik is trusted as the identity gatekeeper. The issue is fixed in versions v2.11.51, v3.6.22, and v3.7.6, which introduce a new underscoreHeadersStrategy configuration option to control how these headers are handled. As of disclosure on July 6, 2026, no public proof-of-concept or in-the-wild exploitation had been reported, though the fix is straightforward to reverse-engineer, so prompt upgrading is advised.\r\n\r\nDetection method: Detection targets the exposed Traefik dashboard by issuing a GET request to \u002Fdashboard\u002F — both on the base URL and on the common :8080 administrative port — while following redirects (since \u002Fdashboard without a trailing slash returns a 301). A match requires both the string Traefik in the response body and a 200 status code, deliberately relying on a version-independent marker rather than build-specific asset hashes (e.g. index-CbBpIoml.js), which change with every release and break detection on the next version. The check stops at the first matching path, keeping the probe lightweight and reliable across Traefik v2 and v3 deployments.","2026-08-10T14:41:17.513441Z","Traefik",[68],{"id":71,"title":72,"summary":73,"published_at":74,"severity":59,"vendor":75,"products":76},149,"Microsoft SharePoint Server - Unauthenticated Deserialization RCE","Microsoft SharePoint Server is an on-premises collaboration and document-management platform that runs on Windows Server and IIS.\r\n\r\nCVE-2026-50522\r\n\r\nCritical (CVSS 9.8) remote code execution flaw that lets an attacker run commands on a SharePoint server without any login or user interaction. The problem is a deserialization weakness (CWE-502): when SharePoint receives a crafted request at its sign-in endpoint, it trusts and rebuilds attacker-supplied data instead of rejecting it, which lets the attacker's code run on the server with the same high privileges as SharePoint itself. Disclosed in Microsoft's July 14, 2026 advisory and demonstrated at Pwn2Own Berlin, it came under active exploitation within hours of a public proof-of-concept on July 20, 2026, with attackers using it to steal the server's machine keys and keep long-term access — which led CISA to add it to its Known Exploited Vulnerabilities catalog. Because the fix is an internal change to how the server handles incoming data, a patched and an unpatched server look the same from the outside, so confirming whether a system is protected requires checking the farm directly rather than scanning it from the network. It affects on-premises SharePoint Server 2016, 2019, and Subscription Edition; SharePoint Online is not affected.","2026-08-10T09:32:36.044856Z","Microsoft",[77],"Microsoft SharePoint Server",{"id":79,"title":80,"summary":81,"published_at":82,"severity":51,"vendor":83,"products":84},148,"WordPress Login Page: Pre-Auth Reflected XSS Chainable to RCE","WHAT IT IS — CVE-2026-64638 is a High severity flaw (CVSS 8.9) on the WordPress login page, published on 6 August 2026 and affecting every version from 4.7 onwards. It lets an attacker run malicious code in the browser of someone visiting the login page, with no account and no prior access to the site. WHY IT HAPPENS — When a login attempt fails, WordPress cleans up the submitted username through two successive filters that interpret the same value differently, and that gap lets attacker-controlled content reach the page. IMPACT — Under specific additional conditions, the flaw can be extended to code execution on the server, giving an attacker full control of the site. WHAT EXPLOITATION REQUIRES — Three conditions must be true at once. (1) The login page must be reachable from the internet, so an interface restricted to an internal network, a VPN or an IP allowlist is out of scope. (2) The attacker must get an administrator to open a page they control, typically through a targeted email or message, while that administrator is already logged in to the site in the same browser; a link to the site alone is not enough. (3) The account targeted must be an Administrator, as lower privileges yield nothing useful. IN SHORT — This is a targeted social engineering scenario, not an attack that scales automatically across sites. HOW WE REPORT IT — A confirmed Qualified vulnerability means an affected version, a login interface exposed to the internet, and a positive response to the test we send to prove the flaw is reachable. A warning means the affected version is present but exploitation could not be demonstrated, either because no login interface is exposed or because the request is blocked upstream, as Cloudflare and Wordfence do by default; the flaw is still there and the block is a mitigating layer rather than a fix, so it needs attention, just with less urgency. RECOMMENDATION — Update to 7.0.3, 6.9.6 or 6.8.7 depending on the branch, or move straight to 7.0.3, keeping in mind automatic minor updates may already have applied the fix. Because the attack depends on an administrator clicking a malicious link, pair the update with user awareness: administrators should not follow links to the administration area received by email or messaging, and should close administrative sessions when not in use. Where operationally feasible, restricting login page access to trusted networks adds a durable layer of protection. ----- ⚠️ NOTE — Some of your assets may appear under \"Warning\" here while also being covered by a related qualified vulnerability. Exploitability has been verified across your entire attack surface, but this specific view does not display non-pentested assets as \"impacted\" — a limitation of how this menu is built, not a gap in coverage. Please refer to the \"Qualified vulnerability\" menu for the authoritative list of affected assets.","2026-08-07T17:12:04.208270Z","wordpress",[83],{"id":86,"title":87,"summary":88,"published_at":89,"severity":59,"vendor":90,"products":91},145,"WordPress Login Page — Pre-Auth Reflected XSS Chainable to RCE","WordPress is an open-source PHP\u002FMySQL content management system (CMS) powering roughly 41% of all websites, built around a theme-and-plugin architecture and a REST API for blogs, sites, and e-commerce.\r\n\r\nCVE-2026-64638\r\n\r\nPre-authentication reflected XSS on the WordPress login screen, patched in 7.0.3 on August 6, 2026 with backports through the 4.7 branch. It needs no privileges and no extra victim interaction for the XSS itself.\r\n\r\nThe root cause is a parser differential in WordPress's own sanitization pipeline: the failed-login username survives strip_tags() as inert text (a tag-like string with whitespace after the opening \u003C) but is later re-interpreted as valid HTML by wp_kses_post(), yielding attacker-controlled DOM on the login page. Those elements hijack core's user-profile.js (loaded there for password resets) by clobbering the undefined ajaxurl variable, steering a same-origin REST request, then abusing REST JSONP (with _envelope=1 to wrap 401s in an outer HTTP 200) to run JavaScript in the site's origin. A nonce-based CSP with strict-dynamic did not stop it.\r\n\r\nEscalation to PHP execution (pwn.ai's \"XSS2Shell\" chain, built on Yibelo's SOME technique) is conditional, not automatic: it requires a logged-in Administrator to click an attacker page, plus Application Passwords, the admin's unfiltered_html\u002Fupload_plugins capabilities, writable plugin storage, and a lack of hardening against PHP execution from inactive plugin directories. Disabling Application Passwords breaks that specific chain but not the underlying XSS — so updating to 7.0.3 (or the relevant backport) is the real fix. No in-the-wild exploitation was reported as of August 7.","2026-08-07T14:44:53.712668Z","Automattic",[92],"WordPress",{"id":94,"title":87,"summary":88,"published_at":89,"severity":59,"vendor":90,"products":95},144,[],{"id":97,"title":87,"summary":98,"published_at":99,"severity":51,"vendor":83,"products":100},146,"CVE-2026-64638: pre-auth XSS on the WordPress login page\r\n\r\nSummary. JavaScript injection on \u002Fwp-login.php. No account, no privileges needed to fire the XSS. Patched August 6, 2026 in WordPress 7.0.3, with backports down to the 4.7 branch. No in-the-wild exploitation reported as of August 7.\r\n\r\nRoot cause. On a failed login, WordPress sanitizes the submitted username through two successive filters that disagree on what the string is. The first one sees inert text. The second one parses the same string as valid HTML. That gap lets an attacker drop their own elements into the login page and get JavaScript running in the site's origin. The CSP in place doesn't stop it.\r\n\r\nImpact. Chained far enough, this reaches PHP execution on the server, so full site compromise. The chain isn't automatic. It needs Application Passwords enabled, plugin install rights on the targeted account, writable plugin storage, and no hardening against PHP execution from inactive plugin directories. Killing Application Passwords breaks that specific chain but leaves the XSS intact. Patching is the only real fix.\r\n\r\nWhat it takes to exploit\r\n\r\nLogin page reachable from the internet. That's the entry condition. Anything behind a VPN, IP allowlist, or upstream auth is out of reach through this vector.\r\n\r\nAn admin has to click. The vulnerable parameter comes in over POST, so there's no crafted URL to paste into a phish. The victim has to hit an attacker-controlled page that submits the request for them. Email, chat message, third-party site, whatever lands. They also need an active admin session in the same browser.\r\n\r\nThe victim has to be an Administrator. Any lower role and the payload does nothing worth having.\r\n\r\nSince the trigger is human, patching alone doesn't close the operational risk. Worth pushing user awareness alongside the update: don't follow links into the admin area sent by mail or chat, and don't sit on an open admin session. This is spearphishing territory, not mass exploitation. One target, one site, one click.\r\n\r\nHow we qualify it\r\n\r\nQualified vulnerability: asset impacted. Vulnerable version, login interface exposed, and our payload comes back positive. Confirmed exploitable, patch now.\r\n\r\nWarning. Vulnerable version but no practical path: either no login page exposed, or the payload gets blocked before it reaches the application. Cloudflare and Wordfence both stop this by default. Still needs patching since the flaw is present and the block is a compensating control, not a fix, but the clock is slower.\r\n\r\nFix : 7.0.3, 6.9.6, or 6.8.7 depending on the branch, or jump straight to 7.0.3. Minor auto-updates cover most of the fleet, so exposure should drop fast.\r\n\r\nNote : the vulnerability has been analyzed as a high risk (not critical as the official CVSS mentionned). For Patrowl,  the prerequisite of exploitation are quite complex (administrator needs to click on a phishing page redirecting to the login page), but the impact is important (possible RCE). We recommend warn wordpress administrator as soon as you can.","2026-08-07T14:44:53Z",[83],{"id":102,"title":87,"summary":103,"published_at":99,"severity":51,"vendor":83,"products":104},147,"WHAT IT IS — CVE-2026-64638 is a High severity flaw (CVSS 8.9) on the WordPress login page, published on 6 August 2026 and affecting every version from 4.7 onwards. It lets an attacker run malicious code in the browser of someone visiting the login page, with no account and no prior access to the site. WHY IT HAPPENS — When a login attempt fails, WordPress cleans up the submitted username through two successive filters that interpret the same value differently, and that gap lets attacker-controlled content reach the page. IMPACT — Under specific additional conditions, the flaw can be extended to code execution on the server, giving an attacker full control of the site. WHAT EXPLOITATION REQUIRES — Three conditions must be true at once. (1) The login page must be reachable from the internet, so an interface restricted to an internal network, a VPN or an IP allowlist is out of scope. (2) The attacker must get an administrator to open a page they control, typically through a targeted email or message, while that administrator is already logged in to the site in the same browser; a link to the site alone is not enough. (3) The account targeted must be an Administrator, as lower privileges yield nothing useful. IN SHORT — This is a targeted social engineering scenario, not an attack that scales automatically across sites. HOW WE REPORT IT — A confirmed vulnerability means an affected version, a login interface exposed to the internet, and a positive response to the test we send to prove the flaw is reachable. A warning means the affected version is present but exploitation could not be demonstrated, either because no login interface is exposed or because the request is blocked upstream, as Cloudflare and Wordfence do by default; the flaw is still there and the block is a mitigating layer rather than a fix, so it needs attention, just with less urgency. RECOMMENDATION — Update to 7.0.3, 6.9.6 or 6.8.7 depending on the branch, or move straight to 7.0.3, keeping in mind automatic minor updates may already have applied the fix. Because the attack depends on an administrator clicking a malicious link, pair the update with user awareness: administrators should not follow links to the administration area received by email or messaging, and should close administrative sessions when not in use. Where operationally feasible, restricting login page access to trusted networks adds a durable layer of protection.",[83],{"id":106,"title":107,"summary":108,"published_at":109,"severity":59,"vendor":60,"products":110},143,"Multiple vulnerabilities in Metabase - Unauthenticated SQL Injection to Admin Access & SQL Injection via Public Dashboard to Admin Access & Arbitrary File Read\u002FWrite","Metabase is an open-source business intelligence (BI) and embedded analytics platform that enables organizations to explore, visualize, and analyze data without requiring SQL expertise.\r\n\r\nGHSA-vwf4-m7j8-wcjf\r\n\r\nA critical SQL injection vulnerability allows unauthenticated remote attackers to inject arbitrary SQL into the Metabase application database through the \u002Fapi\u002Fsession\u002Freset_password endpoint. This vulnerability affects versions ≥ x.58.0 to \u003C x.63.3 and enables attackers to gain administrator access, steal database credentials, read sensitive data, and export information without any authentication. Metabase has confirmed active exploitation in the wild, making immediate patching to versions x.58.24, x.59.21, x.60.17, x.61.11, x.62.9, or x.63.5 critical.\r\n\r\nGHSA-r8h2-qpfx-mx59\r\n\r\nAnother critical SQL injection vulnerability exists in publicly shared dashboards that expose field-filter parameters, affecting the same version ranges as GHSA-vwf4-m7j8-wcjf. An attacker needs only the public link UUID (visible in shared URLs by design) to inject malicious SQL queries and gain full administrator access to the Metabase instance, exfiltrate database credentials, and compromise all connected data sources. Since public sharing is enabled by default in Metabase, any user publishing a shared dashboard with field-filter parameters inadvertently creates this critical exposure.\r\n\r\nGHSA-cwxq-fmxq-jv8h\r\n\r\nGHSA-cwxq-fmxq-jv8h is a critical vulnerability  that affects users able to run native queries or actions against H2 data sources in Metabase, allowing them to read and write arbitrary files on the Metabase server. Since the default sample database is an H2 connection, this vulnerability is exposed by default on all affected Metabase instances. The issue stems from native queries and actions being passed directly to H2 without restricting dangerous host-facing built-in functions such as FILE_READ, FILE_WRITE, CSVREAD, CSVWRITE, and LINK_SCHEMA, which enable unauthorized file system access and linking to external databases.","2026-08-07T12:14:23.415868Z",[111],"Metabase",{"count":113,"next":114,"previous":30,"results":115},25,"http:\u002F\u002Fweb:8606\u002Fapi\u002Farticles\u002F?page=2&sorted_by=-published_at",[116,123,127,134,142,150,157,161,165,172],{"id":113,"title":117,"summary":118,"published_at":119,"type":120,"link":121,"image_url":122},"CVE-2026-64638: XSS2Shell, a WordPress Login Vulnerability","Pre-auth XSS on wp-login.php, patched August 6. What is actually exploitable, and how to read it in your Patrowl report.","2026-08-10T00:00:00Z","cve","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fxss2shell-critical-wordpress-login-vulnerability-2026","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F904e61748b-1786369212\u002Fxss2shell.png",{"id":124,"title":125,"summary":125,"published_at":119,"type":120,"link":126,"image_url":60},24,"CVE-2026-64638 : XSS2Shell, faille du login WordPress","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fcve-2026-64638-xss2shell-faille-login-wordpress",{"id":128,"title":129,"summary":130,"published_at":131,"type":120,"link":132,"image_url":133},23,"How Agentic AI Hunts Down CVEs Before Attackers Do","38 vulnerability sources monitored around the clock, pentester-validated proof of exploitability, an alert within hours. See how it works.","2026-08-05T00:00:00Z","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fproactive-threat-hunting-agentic-ai-cve","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F804988ce7b-1785930160\u002Fproactive-threat-hunting-how-agentic-ai-tracks-cves.png",{"id":135,"title":136,"summary":137,"published_at":138,"type":139,"link":140,"image_url":141},22,"AI Agent Incident: OpenAI HuggingFace — Risks and Lessons","An autonomous AI agent escaped its sandbox via a JFrog Artifactory zero-day, compromised HuggingFace via privilege escalation and stolen credentials. Reconstructed timeline and security lessons.","2026-07-31T00:00:00Z","hacks","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fai-agent-incident-openai-huggingface-risks","[Image URL from Kirby]",{"id":143,"title":144,"summary":145,"published_at":146,"type":147,"link":148,"image_url":149},21,"SaaS Under Watch: What Your SDLC Doesn","Your pipeline is green. Your real exposure may have changed without you knowing it. The complete guide for software vendors.","2026-07-29T00:00:00Z","security tips","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fsecuring-saas-application-software-vendor","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F20d6ec0cd0-1785331401\u002Fapplication-security.png",{"id":151,"title":152,"summary":153,"published_at":154,"type":120,"link":155,"image_url":156},18,"Wp2shell: WordPress Security Flaws","Deep dive into wp2shell vulnerabilities (CVE-2026-63030 & CVE-2026-60137) in WordPress 7.0.2. Detection guide and fixes to secure your sites.","2026-07-20T00:00:00Z","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fwp2shell-critical-wordpress-vulnerabilities","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F97aa11e60b-1784565821\u002Fminiature-wp2shell.png",{"id":158,"title":152,"summary":159,"published_at":154,"type":120,"link":160,"image_url":156},19,"Deep dive into wp2shell vulnerabilities (CVE-2026-63030 & CVE-2026-60137) in WordPress. Detection guide and fixes to secure your sites.","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fwp2shell-critical-wordpress-vulnerabilities-copier",{"id":162,"title":152,"summary":159,"published_at":154,"type":120,"link":163,"image_url":164},20,"https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fwp2shell-critical-wordpress-vulnerabilities-2026","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F97aa11e60b-1784567602\u002Fminiature-wp2shell.png",{"id":166,"title":167,"summary":168,"published_at":169,"type":147,"link":170,"image_url":171},17,"SAST vs DAST vs IAST vs RASP: Which One Do You Need?","Four methods, four moments in the application risk cycle. Compare SAST, DAST, IAST and RASP — and see which one fits your stack, your team and your code access.","2026-07-13T00:00:00Z","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fsast-vs-dast-vs-iast-vs-rasp","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F1d32e651a8-1784299758\u002Fsast-dast-iast-rasp.png",{"id":173,"title":174,"summary":175,"published_at":176,"type":147,"link":177,"image_url":178},16,"NIS2 transposition delays: why waiting is a trap","The substance of NIS2 is fixed by Directive (EU) 2022\u002F2555 and ENISA","2026-07-10T00:00:00Z","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fnis2-transposition-delay","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F33c9b48a9c-1783691971\u002Fnis2-update.png"]