[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"landing-trending":3,"cve-CVE-2026-35039":30,"landing-articles":155},{"count":4,"next":5,"previous":6,"results":7},266,"http:\u002F\u002Fweb:8606\u002Fapi\u002Ftrending_attacks\u002F?page=2&page_size=3&sorted_by=-published_at",null,[8,17,20],{"id":9,"title":10,"summary":11,"published_at":12,"severity":13,"vendor":14,"products":15},265,"Google Brotli decoder - Remote Code Execution via compressed requests (Exploitation Check)","This control is the second step of the Patrowl response to CVE-2026-111497 (Node2Shell). It complements the first control of 22 October 2026, which focused on the Node.js runtime, and does not replace it.\r\n\r\nWhy a second control\r\n\r\nCVE-2026-111497 is an out-of-bounds write in the Google Brotli decoder, the library that decompresses Brotli (\"br\") data. It was first published as a Node.js vulnerability, because Node.js bundles this decoder. Later publications showed that the flaw is in the library itself. Every product that embeds an affected version of the decoder is concerned, whatever its language or vendor. A public proof of concept demonstrates code execution.\r\n\r\nAny server that decompresses request bodies sent with \"Content-Encoding: br\" exposes the decoder to unauthenticated attackers. Known cases include Express 5 and NestJS 11 on Node.js, Koa and Fastify setups, Bun, Envoy and Istio with request decompression enabled, and any application or reverse proxy that decodes Brotli request bodies with an affected library.\r\n\r\nThe flaw also works in the other direction. A malicious server can compromise an unpatched client that decodes a Brotli response, for example Node.js fetch(), Python clients (requests, httpx, aiohttp, Scrapy) with the Brotli or brotlicffi package, or libcurl builds with Brotli support.\r\n\r\nWhat this control checks\r\n\r\nPatrowl sends small, valid Brotli-compressed requests to each asset and observes whether the server decodes them. The check does not depend on the technology: it detects the behaviour, whatever the stack behind it. These requests are what any legitimate client could send. They never reach the vulnerable code path and cannot affect the availability of the service.\r\n\r\nHow to read the result\r\n\r\nPotentially impacted means the asset decodes Brotli request bodies: the attack surface is exposed. It does not confirm that the asset is vulnerable. The version of the Brotli decoder in use is not visible from the outside.\r\n\r\nThis check covers applications that parse request bodies on their root path. A Not impacted result does not rule out exposure on other routes, nor on the client side. Checking the versions on the servers remains the only exhaustive verification.\r\n\r\nAffected and fixed versions\r\n\r\nGoogle Brotli 1.0.3 to 1.2.0 are affected, fixed in 1.0.10, 1.1.1 and 1.2.1. Fixed releases of the main products embedding it: Node.js 22.23.4, 24.22.1 and 26.12.1 (end-of-life lines 20.x and older and 25.x receive no fix), Bun 1.4.4, Envoy 1.37.8, 1.38.6, 1.39.3 and 1.40.0, Istio 1.29.9, 1.30.6 and 1.31.2, Python Brotli 1.2.1 and brotlicffi 1.2.1.0. Products that link against the system library depend on the Brotli package of the Linux distribution.\r\n\r\nRecommendations\r\n\r\nUpdate every component that embeds the Brotli decoder (only real fix). Start with the assets flagged by this control. Restart the processes after the update. Rebuild containers, single-executable applications and appliances that bundle an affected runtime or library.\r\n\r\nReduce the exposure until the update is deployed. Reject requests with \"Content-Encoding: br\" at the reverse proxy, load balancer or WAF, case-insensitively and including lists such as \"gzip, br\". On Envoy and Istio, disable request decompression for Brotli.\r\n\r\nReview outbound calls. List the features that fetch content from servers you do not control, and patch the services that host them first.","2026-10-24T10:37:22.192753Z",4,"google",[16],"brotli",{"id":4,"title":10,"summary":18,"published_at":12,"severity":13,"vendor":14,"products":19},"This control is the second step of the Patrowl response to CVE-2026-111497 (Node2Shell). It complements the first control of 22 October 2026, which focused on the Node.js runtime, and does not replace it.\r\n\r\nWhy a second control\r\n\r\nCVE-2026-111497 is an out-of-bounds write in the Google Brotli decoder, the library that decompresses Brotli (\"br\") data. It was first published as a Node.js vulnerability, because Node.js bundles this decoder. Later publications showed that the flaw is in the library itself. Every product that embeds an affected version of the decoder is concerned, whatever its language or vendor. A public proof of concept demonstrates code execution.\r\n\r\nAny server that decompresses request bodies sent with \"Content-Encoding: br\" exposes the decoder to unauthenticated attackers. Known cases include Express 5 and NestJS 11 on Node.js, Koa and Fastify setups, Bun, Envoy and Istio with request decompression enabled, and any application or reverse proxy that decodes Brotli request bodies with an affected library.\r\n\r\nThe flaw also works in the other direction. A malicious server can compromise an unpatched client that decodes a Brotli response, for example Node.js fetch(), Python clients (requests, httpx, aiohttp, Scrapy) with the Brotli or brotlicffi package, or libcurl builds with Brotli support.\r\n\r\nWhat this control checks\r\n\r\nPatrowl sends small, valid Brotli-compressed requests to each asset and observes whether the server decodes them. The check does not depend on the technology: it detects the behaviour, whatever the stack behind it. These requests are what any legitimate client could send. They never reach the vulnerable code path and cannot affect the availability of the service.\r\n\r\nHow to read the result\r\n\r\nPotentially impacted means the asset decodes Brotli request bodies: the attack surface is exposed. It does not confirm that the asset is vulnerable. The version of the Brotli decoder in use is not visible from the outside.\r\n\r\nThis check covers applications that parse request bodies on their root path. A Not impacted result does not rule out exposure on other routes, nor on the client side. Checking the versions on the servers remains the only exhaustive verification.\r\n\r\nTwo situations are possible. When the decoding is done by your own application or reverse proxy, identify the component and update it. If an update is not possible right away, reject requests with \"Content-Encoding: br\" at the reverse proxy or WAF.\r\n\r\nWhen the asset is hosted on a managed platform or behind a CDN (for example Platform.sh, Upsun or Fastly), the decoding may be done by the provider's edge router, in front of your application. You cannot patch it yourself, but this router handles all the traffic of your site. Ask your provider to confirm that its edge components are patched against CVE-2026-111497. Assets hosted on a managed platform or behind a CDN carry the tag \"paas: platform.sh\" or \"cdn: fastly\" in the asset view: for these assets, the Brotli decoding is done by the provider's edge router, in front of your application, and only the provider can patch it.\r\n\r\nAffected and fixed versions\r\n\r\nGoogle Brotli 1.0.3 to 1.2.0 are affected, fixed in 1.0.10, 1.1.1 and 1.2.1. Fixed releases of the main products embedding it: Node.js 22.23.4, 24.22.1 and 26.12.1 (end-of-life lines 20.x and older and 25.x receive no fix), Bun 1.4.4, Envoy 1.37.8, 1.38.6, 1.39.3 and 1.40.0, Istio 1.29.9, 1.30.6 and 1.31.2, Python Brotli 1.2.1 and brotlicffi 1.2.1.0. Products that link against the system library depend on the Brotli package of the Linux distribution.\r\n\r\nRecommendations\r\n\r\nUpdate every component that embeds the Brotli decoder (only real fix). Start with the assets flagged by this control. Restart the processes after the update. Rebuild containers, single-executable applications and appliances that bundle an affected runtime or library.\r\n\r\nReduce the exposure until the update is deployed. Reject requests with \"Content-Encoding: br\" at the reverse proxy, load balancer or WAF, case-insensitively and including lists such as \"gzip, br\". On Envoy and Istio, disable request decompression for Brotli.\r\n\r\nContact your edge provider about the status of the pathing (Fastly \u002F Plateform.sh)\r\n\r\nReview outbound calls. List the features that fetch content from servers you do not control, and patch the services that host them first.",[16],{"id":21,"title":22,"summary":23,"published_at":24,"severity":13,"vendor":25,"products":26},263,"Oracle Java SE JSSE - Improper Access Control & Unauthorized Data Access & Unauthorized Data Modification","Oracle Java SE is the Java runtime and development platform. Its JSSE (Java Secure Socket Extension) component provides TLS\u002FSSL for secure network communication. Oracle GraalVM is a JDK distribution based on the same platform.\r\n\r\nCVE-2026-91403\r\n\r\nA vulnerability in the JSSE component of Oracle Java SE, Oracle GraalVM for JDK and Oracle GraalVM Enterprise Edition can be exploited by an unauthenticated attacker with network access over multiple protocols. A successful attack can give unauthorized access to critical data and allow unauthorized creation, deletion or modification of data. It can also affect sandboxed Java Web Start applications and applets that run untrusted code. The record lists the weakness as CWE-284 (Improper Access Control) in the CISA ADP entry, while another database lists CWE-295. The record lists these affected versions:\r\n- Oracle Java SE: 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1.\r\n- Oracle GraalVM for JDK: 17.0.21, 21.0.13.\r\n- Oracle GraalVM Enterprise Edition: 21.3.20.\r\n\r\nOracle published an out-of-cycle Security Alert on October 21, 2026. One secondary source says the fix makes Java distrust eight compromised intermediate CA certificates shipped with the JDK. The Oracle-focused sources do not confirm this root cause, so check it against the Oracle advisory. CISA ADP SSVC data shows Exploitation: none, Automatable: yes, Technical Impact: total. The CVE is not in the CISA KEV catalog as of October 22, 2026, and its EPSS score is below 1%.","2026-10-23T14:12:32.871954Z","Oracle",[27,28,29],"Oracle Java SE","Oracle GraalVM Enterprise Edition","Oracle GraalVM for JDK",{"id":31,"cve_id":32,"euvd_id":33,"summary":34,"published":35,"cvss_data":36,"is_remote":47,"cwes":48,"cpes":52,"technologies":55,"references":58,"score":63,"epss_score":64,"epss_percentile":65,"is_kev":66,"cisa_kev_date_added":6,"cisa_kev_due_date":6,"cisa_ssvc":67,"attack_mappings":77,"exploits":154},20379,"CVE-2026-35039","EUVD-2026-19380","fast-jwt: Cache Confusion via cacheKeyBuilder Collisions Can Return Claims From a Different Token (Identity\u002FAuthorization Mixup)\n\n_NOTE_: While the library exposes a mechanism which could introduce the vulnerability, this issue is created by developer-supplied code and not by the library itself. We will add a warning and some education for users around the possible issues however since the defaults work we will not be updating the library beyond that for this advisory.\n\n## Impact\n\nSetting up a custom cacheKeyBuilder method which does not properly create unique keys for different tokens can lead to cache collisions. This could cause tokens to be mis-identified during the verification process leading to:\n\n- Valid tokens returning claims from different valid tokens\n- Users being mis-identified as other users based on the wrong token\n\nThis could result in:\n- User impersonation - UserB receives UserA's identity and permissions\n- Privilege escalation - Low-privilege users inherit admin-level access\n- Cross-tenant data access - Users gain access to other tenants' resources\n- Authorization bypass - Security decisions made on wrong user identity\n\n## Affected Configurations\n\nThis vulnerability ONLY affects applications that BOTH:\n\n1. Enable caching using the cache option\n2. Use custom cacheKeyBuilder functions that can produce collisions\n\nVULNERABLE examples:\n```\n\u002F\u002F Collision-prone: same audience = same cache key\ncacheKeyBuilder: (token) => {\n  const { aud } = parseToken(token)\n  return `aud=${aud}`\n}\n\n\u002F\u002F Collision-prone: grouping by user type\ncacheKeyBuilder: (token) => {\n  const { aud } = parseToken(token)\n  return aud.includes('admin') ? 'admin-users' : 'regular-users'\n}\n\n\u002F\u002F Collision-prone: tenant + service grouping\ncacheKeyBuilder: (token) => {\n  const { iss, aud } = parseToken(token)\n  return `${iss}-${aud}`\n}\n```\n\nSAFE examples:\n```\n\u002F\u002F Default hash-based (recommended)\ncreateVerifier({ cache: true })  \u002F\u002F Uses secure default\n\n\u002F\u002F Include unique user identifier\ncacheKeyBuilder: (token) => {\n  const { sub, aud, iat } = parseToken(token)\n  return `${sub}-${aud}-${iat}`\n}\n\n\u002F\u002F No caching (always safe)\ncreateVerifier({ cache: false })\n```\n### Not Affected\n\n- Applications using **default caching**\n- Applications with **caching disabled**\n \n## Assessment Guide\n\nTo determine if you're affected:\n\n1. Check if caching is enabled: Look for cache: true or cache: \u003Cnumber> in verifier configuration\n2. Check for custom cache key builders: Look for cacheKeyBuilder function in configuration\n3. Analyze collision potential: Review if your cacheKeyBuilder can produce identical keys for different users\u002Ftokens\n4. If no custom cacheKeyBuilder: You are NOT affected (default is safe)\n\n## Mitigations\n\nMitigations include:\n\n- Ensure uniqueness of keys produced in cacheKeyBuilder\n- Remove custom cacheKeyBuilder method\n- Disable caching\n\n---\n\nfast-jwt allows enabling a verification cache through the cache option.\nThe cache key is derived from the token via cacheKeyBuilder.\n\nWhen a custom cacheKeyBuilder produces collisions between different tokens, the verifier may return the cached payload of a previous token instead of validating and returning the payload of the current token.\n\nThis results in cross-token payload reuse and identity confusion.\n\nTwo distinct valid JWTs can be verified successfully but mapped to the same cached entry, causing the verifier to return claims belonging to a different token.\n\nThis affects authentication and authorization decisions when applications trust the returned payload.\n\nAffected component\n\nsrc\u002Fverifier.js\n\nRelevant logic:\n\ncache enabled via createCache\n\ncache population via cacheSet\n\nlookup based on cacheKeyBuilder(token)\n\ncached payload returned without re-verification\n\nImpact\n\nIdentity \u002F authorization confusion via cache collision.\n\nIf two tokens generate the same cache key:\n\ntoken A is verified → payload stored in cache\n\ntoken B is verified → cache hit occurs\n\nverifier returns payload from token A instead of B\n\nObserved effect:\n\nsubject mismatch\n\nclaim mismatch\n\nauthorization decision performed on wrong identity\n\nPotential real-world consequences:\n\nuser impersonation (logical)\n\nprivilege confusion\n\nincorrect RBAC evaluation\n\ngateway \u002F middleware auth inconsistencies\n\nThis is especially dangerous when:\n\ncache is enabled (recommended for performance)\n\ncustom cacheKeyBuilder is used\n\nidentity claims (sub \u002F aud \u002F iss) drive authorization\n\nRoot cause\n\nThe verifier assumes the cache key uniquely identifies the token and its claims.\n\nHowever:\n\ncacheKeyBuilder is user-controlled\n\ncollisions are not detected\n\ncache entries store decoded payload\n\ncached payload is returned without binding validation\n\nThis creates a trust boundary break between:\n\ntoken → cache key → cached payload\n\nProof of concept\n\nEnvironment:\n\nfast-jwt: 6.1.0\n\nNode.js: v24.13.1\n\nPoC:\n\nconst { createSigner, createVerifier } = require('fast-jwt')\n\nconst sign = createSigner({ key: 'secret' })\n\n\u002F\u002F Two distinct tokens\nconst t1 = sign({ sub: 'userA', aud: 'admin' })\nconst t2 = sign({ sub: 'userB', aud: 'admin' })\n\n\u002F\u002F Deliberately unsafe cache key builder (collision)\nconst verify = createVerifier({\n  key: 'secret',\n  cache: true,\n  cacheKeyBuilder: () => 'static-key'\n})\n\nconsole.log('verify t1')\nconst p1 = verify(t1)\nconsole.log('t1 PASS sub=', p1.sub)\n\nconsole.log('verify t2')\nconst p2 = verify(t2)\nconsole.log('t2 PASS sub=', p2.sub)\n\nconsole.log('verify t2 again')\nconst p3 = verify(t2)\nconsole.log('t2-again PASS sub=', p3.sub)\n\nconsole.log('verify t1 again')\nconst p4 = verify(t1)\nconsole.log('t1-again PASS sub=', p4.sub)\n\nObserved output:\n\nverify t1\nt1 PASS sub= userA\n\nverify t2\nt2 PASS sub= userA\n\nverify t2 again\nt2-again PASS sub= userA\n\nverify t1 again\nt1-again PASS sub= userA\n\nThe verifier returns payload from userA when verifying userB.\n\nExpected behavior\n\nCache must not allow returning claims from a different token.\n\nVerification must remain bound to the actual token being validated.\n\nEven if cache collisions occur, the verifier should:\n\nrevalidate signature\n\nre-decode payload\n\nor invalidate cache entry\n\nWhy this is not “just misuse”\n\nThis is not merely a user mistake.\n\nReasons:\n\nfast-jwt explicitly exposes cacheKeyBuilder as an extension point.\n\nThe documentation suggests performance tuning via custom key builders.\n\nNo safeguards exist against collisions.\n\nNo verification binding is performed between:\n\ncached payload\n\noriginal token\n\nThe verifier trusts cache output as authoritative identity.\n\nThis creates a security-sensitive invariant:\n\n\"cache key uniqueness\"\n\nwhich is neither enforced nor validated.\n\nSecurity-critical libraries must assume extension hooks can be misused and implement defensive checks, especially when identity decisions are derived from cached values.\n\nSecurity classification\n\nlogical authorization flaw\n\ncache confusion vulnerability\n\nidentity boundary break\n\nClosest CWE:\n\nCWE-440 — Expected Behavior Violation\n\nSuggested fix (minimal and safe)\n\nBind cache entries to token integrity.\n\nOption A — safest:\n\nStore token hash along with payload and verify match before returning cache.\n\nConceptual patch:\n\nconst tokenHash = hashToken(token)\n\ncache.set(key, { tokenHash, payload })\n\n...\n\nconst entry = cache.get(key)\n\nif (entry && entry.tokenHash === hashToken(token)) {\n  return entry.payload\n}\n\nOption B — simpler:\n\nDisable cache usage when custom cacheKeyBuilder is provided.\n\nOption C — defensive:\n\nAlways re-validate signature when cache hit occurs.\n\nNotes\n\nDefault cacheKeyBuilder is safe (hash-based).\n\nIssue appears when custom builders are used — a documented and supported feature.\n\nImpact increases in:\n\nAPI gateways\n\nauth middleware\n\nRBAC layers relying on payload.sub \u002F payload.aud\n\nThis vulnerability is independent from:\n\nRegExp statefulness issue\n\nReDoS claim validation issue\n\nIt is a separate flaw in cache design and trust model.\n\nPoC did on my computer:\n'use strict'\n\nconst fs = require('node:fs')\nconst path = require('node:path')\nconst { createSigner, createVerifier } = require('.\u002Fsrc')\n\nfunction nowSec() {\n  return Math.floor(Date.now() \u002F 1000)\n}\n\nconst sign = createSigner({ key: 'secret' })\nconst t1 = sign({ sub: 'userA', aud: 'admin', iat: nowSec() })\nconst t2 = sign({ sub: 'userB', aud: 'admin', iat: nowSec() })\n\nfunction badKeyBuilder() {\n  return 'aud=admin'\n}\n\nconst verify = createVerifier({\n  key: 'secret',\n  cache: true,\n  cacheTTL: 60000,\n  cacheKeyBuilder: badKeyBuilder\n})\n\nfunction run(tok) {\n  try {\n    const out = verify(tok)\n    return { ok: true, sub: out.sub, aud: out.aud }\n  } catch (e) {\n    return { ok: false, code: e.code || String(e), message: e.message }\n  }\n}\n\nconst results = []\nresults.push({ step: 'verify(t1)', token: 't1', result: run(t1) })\nresults.push({ step: 'verify(t2)', token: 't2', result: run(t2) })\nresults.push({ step: 'verify(t2) again', token: 't2', result: run(t2) })\nresults.push({ step: 'verify(t1) again', token: 't1', result: run(t1) })\n\nconst evidence = {\n  title: 'fast-jwt cache confusion when cacheKeyBuilder collisions occur',\n  environment: {\n    node: process.version,\n    fastJwt: require('.\u002Fpackage.json').version\n  },\n  config: {\n    cache: true,\n    cacheTTL: 60000,\n    cacheKeyBuilder: \"returns constant key 'aud=admin' (realistic collision pattern)\"\n  },\n  tokens: {\n    t1: { claims: { sub: 'userA', aud: 'admin' }, jwt: t1 },\n    t2: { claims: { sub: 'userB', aud: 'admin' }, jwt: t2 }\n  },\n  observed: results\n}\n\nconst outPath = path.join(process.cwd(), 'evidence-cache-keybuilder-confusion.json')\nfs.writeFileSync(outPath, JSON.stringify(evidence, null, 2))\nconsole.log('Wrote evidence to:', outPath)\n\nfor (const r of results) {\n  console.log(r.step, '=>', r.result.ok ? `PASS sub=${r.result.sub}` : `FAIL ${r.result.code}`)\n}\n\nOutput:\nPS C:\\Users\\Franciny Rojas\\Desktop\\crypto-research\\fast-jwt> node poc_cache_keybuilder_confusion_evidence.js\nWrote evidence to: C:\\Users\\Franciny Rojas\\Desktop\\crypto-research\\fast-jwt\\evidence-cache-keybuilder-confusion.json\nverify(t1) => PASS sub=userA\nverify(t2) => PASS sub=userA\nverify(t2) again => PASS sub=userA\nverify(t1) again => PASS sub=userA\nPS C:\\Users\\Franciny Rojas\\Desktop\\crypto-research\\fast-jwt>","2026-04-03T04:07:00Z",{"cvss_v3.1":37},{"scope":38,"version":39,"baseScore":40,"attackVector":41,"baseSeverity":42,"vectorString":43,"integrityImpact":44,"userInteraction":45,"attackComplexity":46,"availabilityImpact":45,"privilegesRequired":45,"confidentialityImpact":44},"UNCHANGED","3.1",9.1,"NETWORK","CRITICAL","CVSS:3.1\u002FAV:N\u002FAC:L\u002FPR:N\u002FUI:N\u002FS:U\u002FC:H\u002FI:H\u002FA:N","HIGH","NONE","LOW",true,[49,50,51],"CWE-345","CWE-1289","CWE-706",[53,54],"cpe:2.3:a:nearform:fast-jwt:*:*:*:*:*:node.js:*:*","cpe:2.3:a:fast-jwt:fast-jwt:*:*:*:*:*:*:*:*",[56,57],"Nearform Fast-Jwt","Fast-Jwt Fast-Jwt",[59,60,61,62],"https:\u002F\u002Fgithub.com\u002Fnearform\u002Ffast-jwt\u002Fcommit\u002Fde121056c6415b58770c60640881eaec67ac4ceb","https:\u002F\u002Fgithub.com\u002Fnearform\u002Ffast-jwt\u002Fsecurity\u002Fadvisories\u002FGHSA-rp9m-7r4c-75qg","https:\u002F\u002Fnvd.nist.gov\u002Fvuln\u002Fdetail\u002FCVE-2026-35039","https:\u002F\u002Fgithub.com\u002Fnearform\u002Ffast-jwt",0.66,0.00212,0.11414,false,{"timestamp":68,"automatable":69,"tech_impact":70,"exploitation":71,"cisa_decision":72,"cisa_remediation_timeline":76},"2026-04-07T14:25:32.378641Z","yes","total","none",{"vector":73,"decision":74,"priority":75},"CISAv1\u002FE:N\u002FA:Y\u002FT:T\u002FM:H\u002F2026-10-26T09:34:50.985419\u002F","attend","medium","3D",[78,84,93,100,108,115,123,131,139,146],{"name":79,"source":80,"tactics":81,"technique_id":83},"Exploit Public-Facing Application","attack_vector",[82],"initial-access","T1190",{"name":85,"source":86,"cwe_ids":87,"tactics":88,"capec_ids":90,"technique_id":92},"Masquerading","capec",[51],[89],"stealth",[91],"CAPEC-177","T1036",{"name":94,"source":86,"cwe_ids":95,"tactics":96,"capec_ids":97,"technique_id":99},"Exploitation for Stealth",[49],[89],[98],"CAPEC-665","T1211",{"name":101,"source":86,"cwe_ids":102,"tactics":103,"capec_ids":105,"technique_id":107},"Defacement",[49],[104],"impact",[106],"CAPEC-148","T1491",{"name":109,"source":86,"cwe_ids":110,"tactics":111,"capec_ids":113,"technique_id":114},"Component Firmware",[49],[112,89],"persistence",[98],"T1542.002",{"name":116,"source":86,"cwe_ids":117,"tactics":118,"capec_ids":121,"technique_id":122},"Modify Authentication Process",[49],[119,120,112],"credential-access","defense-impairment",[98],"T1556",{"name":124,"source":86,"cwe_ids":125,"tactics":126,"capec_ids":128,"technique_id":130},"ARP Cache Poisoning",[49],[127,119],"collection",[129],"CAPEC-141","T1557.002",{"name":132,"source":86,"cwe_ids":133,"tactics":134,"capec_ids":136,"technique_id":138},"DLL",[51],[135,89],"execution",[137],"CAPEC-641","T1574.001",{"name":140,"source":86,"cwe_ids":141,"tactics":142,"capec_ids":143,"technique_id":145},"Path Interception by Search Order Hijacking",[51],[135,89],[144],"CAPEC-159","T1574.008",{"name":147,"source":86,"cwe_ids":148,"tactics":149,"capec_ids":151,"technique_id":153},"DNS Server",[49],[150],"resource-development",[152],"CAPEC-142","T1584.002",[],{"count":156,"next":157,"previous":6,"results":158},26,"http:\u002F\u002Fweb:8606\u002Fapi\u002Farticles\u002F?page=2&page_size=3&sorted_by=-published_at",[159,167,175],{"id":160,"title":161,"summary":162,"published_at":163,"type":164,"link":165,"image_url":166},30,"PHP2Shell: Two Critical RCE Flaws in PHP (CVSS 9.2)","Unauthenticated code execution demonstrated on WordPress, Drupal and Joomla, and reproduced in our lab. Patched versions and steps to take today.","2026-10-22T00:00:00Z","cve","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fphp2shell-2-critical-rce-flaws-php-cvss-9-2","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002Fc0615c4ee6-1792684469\u002Fphp2shell-2-critical-rce-flaws-php-cvss-9-2.png",{"id":168,"title":169,"summary":170,"published_at":171,"type":172,"link":173,"image_url":174},29,"Manage External Security Across All Your Entities","Centralize the management of entities, users and external security resources while maintaining strict data isolation with Patrowl.","2026-09-15T00:00:00Z","security tips","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fmulti-entity-external-security-how-structure-governance-group-level","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F8b2c0cc5eb-1789551467\u002Fvisu_1_multi_tenancy_dark_1x.webp",{"id":176,"title":177,"summary":178,"published_at":179,"type":180,"link":181,"image_url":182},28,"Will AI Become the Next Hacker? Bruce Schneier Answers at DEF CON 34","Tax law, finance, legislation: Bruce Schneier shows how AI could hack human rule systems just as easily as it hacks software.","2026-09-14T00:00:00Z","hacks","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fbruce-schneier-def-con-34","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F5c616d9db4-1789462598\u002Fai-hacker.en.png"]