Search: ye.call

mcp-memory-service is a semantic memory layer for AI applications. Prior to version 10.65.3, the HTTP MCP JSON-RPC endpoint at `/mcp` requires only OAuth `read` scope for all requests, then dispatches `tools/call` directly to handlers that include mutating tools. A read-only OAuth client can call `store_memory` and `delete_memory` through MCP even though the corresponding REST endpoints require `write` scope. Version 10.65.3 patches the issue.

SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS '<description>'`` for a user-supplied description field. The Jinja templates for Domains (and their constraints), Foreign Tables, Languages, and Event Triggers, plus the Views OID-lookup query, interpolated the description directly inside a single-quoted SQL literal -- ``'{{ data.description }}'`` -- instead of passing it through the ``qtLiteral`` escape filter. An authenticated pgAdmin user with permission to create or alter the affected object types could submit a description containing an apostrophe, break out of the literal and chain arbitrary SQL. The injected SQL runs under the PostgreSQL role the user is already authenticated as; for a connected role with ``COPY ... TO/FROM PROGRAM`` (typically PostgreSQL superuser), this chains to OS command execution on the PostgreSQL host. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through pgAdmin's Query Tool -- so the attacker gains no capability beyond what their database role already grants. The marginal impact captures bypass of any application-layer Query Tool gating an operator may have configured. The defect was originally reported against the Domain Dialog ``description`` field; a code-wide audit identified sixteen sites of the same pattern across the templates listed above. The same review also surfaced ten related sinks in the pgstattuple/pgstatindex stats templates -- ``pgstattuple('{{schema}}.{{table}}')`` and the matching pgstatindex shape -- where ``qtIdent`` escapes embedded double quotes inside the identifier but not apostrophes, so a user with CREATE privilege on a schema could plant a table or index named ``foo'bar`` and a later stats viewer would render an unbalanced literal. Fix is layered: 1. Sites: replace every ``'{{ x.description }}'`` with ``{{ x.description|qtLiteral(conn) }}`` (no surrounding quotes -- the filter wraps the value in escaped quotes itself). Plumb ``conn=self.conn`` through every ``render_template`` call that loads one of these templates. Also corrects a ``{ % elif`` Jinja typo in the foreign-table schema diff (dead branch). Rewrite the ten pgstattuple/pgstatindex stats sites to address the relation via OID + ``::oid::regclass`` cast (e.g. ``pgstattuple({{ tid }}::oid::regclass)``), eliminating the embedded literal-call form entirely so that bug-class can no longer recur there. 2. Driver hardening: ``qtLiteral`` (in ``utils/driver/psycopg3/__init__.py``) used to silently return the raw unescaped value when its ``conn`` argument was falsy. It now raises ``ValueError`` -- surfacing the entire bug class going forward. The change immediately uncovered eight latent plumbing bugs (in ``schemas/__init__.py``, ``schemas/functions/__init__.py``, ``schemas/tables/utils.py``, ``foreign_servers/__init__.py``, and seven sites in ``roles/__init__.py``) -- all fixed as part of this patch. The inner ``except`` block that swallowed adapter-level failures and returned the raw value is also removed, so unadaptable inputs raise instead of leaking unescaped values. 3. Regression tests: a per-template behavioural test renders each previously-vulnerable template with an apostrophe-injection payload and asserts the escaped fragment is present and the vulnerable fragment absent; a lint test walks every ``*.sql`` template flagging any ``'{{ ... }}'`` single-quote-wrapped interpolation against an explicit allowlist; unit tests cover the new qtLiteral fail-fast and inner-except raise paths. This issue affects pgAdmin 4: from 1.0 before 9.16.

In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for "e"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note "e"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 </IRQ> <TASK> __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---

Line Desktop MCP is a project that, while unaffiliated with the official line-bot-mcp-server, allows users to directly operate the LINE Desktop application on Windows or Mac via MCP. `line-desktop-mcp` supports a `--http-mode` Streamable HTTP transport for use with clients such as n8n. In this mode the server binds to `0.0.0.0` and exposes the MCP `/mcp` endpoint without an MCP-layer authentication check. Prior to version 1.1.2, any network client that can reach the port can initialize a session, list tools, and call tools that read LINE Desktop chat history or send LINE messages through the already logged-in desktop application. Version 1.1.2 fixes the issue.

Stored cross-site scripting in pgAdmin 4's error-rendering and plan-node-rendering paths. Text returned by a PostgreSQL server (ErrorResponse messages, including object names quoted back inside relation-does-not-exist errors and inside EXPLAIN Recheck Cond / Exact Heap Blocks fields) was passed verbatim through html-react-parser at every user-facing sink — the notifier toasts, FormFooterMessage / FormInput help and error areas, FormNote, ModalProvider AlertContent and confirmDelete, ToolErrorView, the Explain visualiser's NodeText panel, the SQL editor confirm dialogs, ConfirmSaveContent, PreferencesHelper modal alerts, and SelectThemes helper text. A PostgreSQL server an attacker controls — or any server returning attacker-influenced text such as a table or column name a low-privilege database user can create — could inject arbitrary HTML (including <iframe>) into the pgAdmin DOM the moment the victim's pgAdmin connected to that server or viewed an Explain plan that referenced the crafted object. The injected iframe's srcdoc could fetch attacker-served JavaScript and, by writing to parent.location, redirect the victim's top-level pgAdmin browser tab to an attacker-controlled URL. Because the injection originates from inside pgAdmin's own interface, standard anti-clickjacking controls (X-Frame-Options, Content-Security-Policy: frame-ancestors) do not mitigate it. A phishing page rendered inside the legitimate pgAdmin window is indistinguishable from a genuine pgAdmin dialog. Fix combines three complementary layers. (1) DOMPurify sanitisation is wrapped around every html-react-parser call site reachable from notifier, alert, form-error, Explain, and SQL-editor flows. (2) A new plain-text rendering contract — SafeMessage / SafeHtmlMessage components plus Notifier.errorText / alertText / warningText / infoText / successText helpers — is introduced; around fifty callers across browser, tools, dashboard, debugger, misc, llm, preferences, schema diff, and the SQL editor that previously interpolated backend-derived strings are migrated to the plain-text variants. (3) Backend HTML-escape is applied at the post-connection-SQL handler (execute_post_connection_sql) via a new sanitize_external_text helper, so third-party JSON consumers (audit logs, API clients) never receive raw markup either; the Explain plan-info renderer is also patched to _.escape Recheck Cond and Exact Heap Blocks at construction (matching every sibling field), giving defence in depth even before DOMPurify runs. This issue affects pgAdmin 4: from 6.0 before 9.16.

SQL injection in pgAdmin 4's named restore point endpoint (POST /browser/server/restore_point/{gid}/{sid}). The user-supplied 'value' field was interpolated directly into the SQL string with str.format() instead of being passed as a bound parameter, allowing an authenticated pgAdmin user with a connected PostgreSQL session to inject additional statements through that endpoint. The injected SQL executes under the database role the user is already authenticated as. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through the Query Tool -- so the attacker gains no capability beyond what their database role already grants them. The marginal impact accounts for the fact that the injection path is not the documented SQL-execution interface, so a deployment that gates the Query Tool at the application layer could see SQL executed through a path it did not anticipate. Fix passes the restore point name as a bound parameter and schema-qualifies the function call as pg_catalog.pg_create_restore_point so a non-default search_path on the connection cannot redirect the call to a shadow definition. A regression test asserts the value arrives as a bound parameter and not spliced into the SQL string. This issue affects pgAdmin 4: from 1.0 before 9.16.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (e19daf4f946816f5ba3c6e592eacc980861b281c6752b738de57fdd31f49279d) The package masquerades as a Tailwind plugin: README and the top of src/index.js are a verbatim clone of @tailwindcss/typography (require('tailwindcss/plugin'), prose-* class generator), even though the package name has no relationship to Tailwind. Appended after the cloned plugin code at src/index.js:124+ is a heavily obfuscated IIFE using an RC4-decoded string array and AES-decipher key table to hide its strings and control flow. The decoded action table contains keys 'cmd.npx', 'cmd.npxwin', 'pkg.link', 'cmd.install', 'flag.yes', which are consumed by helpers that call child_process.spawn with detached:true, stdio:'ignore', windowsHide:true and creationFlags set to DETACHED_PROCESS to silently run `npx -y <pkg.link>`, fetching and executing an attacker-controlled package from the npm registry on the developer's machine. On Windows an additional path uses keys 'ext.vbs', 'vbs.tag', 'win.wscript': a VBS file is written to os.tmpdir() with a crypto.randomBytes(4) hex prefix and launched via wscript.exe (detached, windowsHide), followed by process.exit(0), to hide the dropper invocation from the console. The action table also contains 'env.api' and 'api.base' entries, and the spawn helper clones process.env and injects api.base as the env.api value into the child, so the downstream npx-fetched package receives a C2/telemetry endpoint via environment. Because require('classbreeze-utils') is the plugin entry point loaded by any Tailwind build that adds it, the dropper fires automatically as soon as a build that depends on it runs, executing arbitrary attacker-controlled code on the developer/CI machine. ## Source: ghsa-malware (cd3cdd1459bd1dce092c75b17f3940659f740a4efe533ba30b345976cef97736) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

mcp-server-kubernetes is a Model Context Protocol server for Kubernetes cluster management. Prior to version 3.6.0, mcp-server-kubernetes exposes three environment variables (ALLOW_ONLY_READONLY_TOOLS, ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS, ALLOWED_TOOLS) documented as access controls for restricting which Kubernetes operations are available. These controls are enforced at the tool discovery layer (tools/list) but not at the execution layer (tools/call). Any client that knows a tool name can invoke it directly regardless of the configured restriction mode. The access control was effectively cosmetic. This issue has been patched in version 3.6.0.

`src/main/java/org/springframework/data/mapping/context/PersistentPropertyPathFactory.java:175` · Unbounded Resource Allocation (Algorithmic DoS) ### Impact When a consuming module routes user-supplied dot-paths (sort parameters, projection paths, PATCH paths) through `MappingContext.getPersistentPropertyPath(String, Class)`, each distinct string — including invalid ones — is cached forever. A remote attacker can send millions of requests with unique `?sort=aaaa<n>` values and grow the heap until the service OOMs. ### Description `PersistentPropertyPathFactory.propertyPaths` (line 53) is a `ConcurrentHashMap<TypeAndPath, PathResolution>` populated by `getPotentiallyCachedPath()` (line 174-177) via `computeIfAbsent`. The key is `(TypeInformation, rawPathString)`. Crucially, unresolvable paths are also cached (as `PathResolution.unresolved`, line 204) so that the same `InvalidPersistentPropertyPath` can be re-thrown — meaning every distinct garbage string an attacker sends creates a permanent entry. There is no eviction. This is reachable from `AbstractMappingContext.getPersistentPropertyPath(String, Class)` (`AbstractMappingContext.java:345`), which Spring Data REST and several store query mappers call with HTTP-request-derived sort/filter property names. By contrast, the sibling `SimplePropertyPath.cache` was already hardened to use `ConcurrentReferenceHashMap` (soft refs); this cache was not given the same treatment. ### Exploit scenario Against a Spring Data REST endpoint, an attacker scripts `GET /things?sort=<random-40-char-string>` in a loop. Each request fails fast with `InvalidPersistentPropertyPath`, but each distinct random string leaves behind a `TypeAndPath` key, a `PathResolution` object holding the split segments list, and the source string in the map. After ~10M requests the JVM OOMs. ### Preconditions - A downstream component (Spring Data REST, a store-specific `QueryMapper`, or application code) passes externally-supplied strings to `MappingContext.getPersistentPropertyPath(String, ...)` - No upstream rate-limiting or path-string validation ### How to fix A cache whose key can be derived from external input must be bounded. Replace `propertyPaths` (line 53) with a `ConcurrentLruCache<TypeAndPath, PathResolution>` of fixed capacity, or `ConcurrentReferenceHashMap` (matching the sibling `SimplePropertyPath.cache`). Additionally, do not cache `PathResolution.unresolved` results at all (line 204 in `createPersistentPropertyPath`) — re-computing a failed lookup is cheap, and caching negative results for arbitrary attacker strings is what makes this exploitable. ### Adversarial verification **Verdict:** TRUE_POSITIVE (confidence: 7/10) — unbounded hard-ref `ConcurrentHashMap` keyed by raw path string, caches unresolved entries (line 204), reachable via public `MappingContext.getPersistentPropertyPath(String, ...)`; sibling `PropertyPath` cache was already converted to soft-refs but this one was missed. -3 confidence because the HTTP-input wiring lives in downstream modules (Spring Data REST / store mappers), not verifiable in this repo. **Code at the line — CONFIRMED** - Line 53: `private final Map<TypeAndPath, PathResolution> propertyPaths = new ConcurrentHashMap<>();` — plain CHM, hard refs, no eviction, no size bound. - Line 175: `propertyPaths.computeIfAbsent(TypeAndPath.of(type, propertyPath), ...)` — every distinct `(type, string)` pair is inserted. - Line 204: `return PathResolution.unresolved(parts, segment, type, currentPath);` — returned from inside `computeIfAbsent`'s mapping function, so unresolvable paths are cached. The `PathResolution` retains the full attacker string (`source = StringUtils.collectionToDelimitedString(parts, ".")`, line 452). **Callers within spring-data-commons** - `AbstractMappingContext.getPersistentPropertyPath(String, Class<?>)` (line 345) and `(String, TypeInformation<?>)` (line 350) → `persistentPropertyPathFactory.from(type, propertyPath)` → straight into the unbounded cache. No validation, no `PropertyPath.from` gate. - This is the public `MappingContext` interface (`MappingContext.java:174,186`), documented to throw `InvalidPersistentPropertyPath` on bad input — i.e., the contract explicitly anticipates being called with possibly-invalid strings. - No in-repo caller routes HTTP input directly into the `String` overload. The `Sort.Order.property` → `getPersistentPropertyPath(String, ...)` bridge lives in store modules (Spring Data MongoDB `QueryMapper`, Spring Data REST sort translator). That wiring is out-of-repo as the finding states. **Protections — NONE on this cache** Contrast: `SimplePropertyPath.java:52` (the `PropertyPath.from` cache) uses `ConcurrentReferenceHashMap` (soft refs, GC-evictable). Spring already hardened the sibling cache against exactly this pattern. `PersistentPropertyPathFactory.propertyPaths` was not given the same treatment. **Stress-test** Is this exclusion #3 (intended design)? The `PathResolution` javadoc (line

In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix held lock freed on hfsplus_fill_super() hfsplus_fill_super() calls hfs_find_init() to initialize a search structure, which acquires tree->tree_lock. If the subsequent call to hfsplus_cat_build_key() fails, the function jumps to the out_put_root error label without releasing the lock. The later cleanup path then frees the tree data structure with the lock still held, triggering a held lock freed warning. Fix this by adding the missing hfs_find_exit(&fd) call before jumping to the out_put_root error label. This ensures that tree->tree_lock is properly released on the error path. The bug was originally detected on v6.13-rc1 using an experimental static analysis tool we are developing, and we have verified that the issue persists in the latest mainline kernel. The tool is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available. We confirmed the bug by runtime testing under QEMU with x86_64 defconfig, lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we used GDB to dynamically shrink the max_unistr_len parameter to 1 before hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and exercises the faulty error path. The following warning was observed during mount: ========================= WARNING: held lock freed! 7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted ------------------------- mount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there! ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 2 locks held by mount/174: #0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40 #1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 stack backtrace: CPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x82/0xd0 debug_check_no_locks_freed+0x13a/0x180 kfree+0x16b/0x510 ? hfsplus_fill_super+0xcb4/0x18a0 hfsplus_fill_super+0xcb4/0x18a0 ? __pfx_hfsplus_fill_super+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? bdev_open+0x65f/0xc30 ? srso_return_thunk+0x5/0x5f ? pointer+0x4ce/0xbf0 ? trace_contention_end+0x11c/0x150 ? __pfx_pointer+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? bdev_open+0x79b/0xc30 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? vsnprintf+0x6da/0x1270 ? srso_return_thunk+0x5/0x5f ? __mutex_unlock_slowpath+0x157/0x740 ? __pfx_vsnprintf+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? mark_held_locks+0x49/0x80 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? irqentry_exit+0x17b/0x5e0 ? trace_irq_disable.constprop.0+0x116/0x150 ? __pfx_hfsplus_fill_super+0x10/0x10 ? __pfx_hfsplus_fill_super+0x10/0x10 get_tree_bdev_flags+0x302/0x580 ? __pfx_get_tree_bdev_flags+0x10/0x10 ? vfs_parse_fs_qstr+0x129/0x1a0 ? __pfx_vfs_parse_fs_qstr+0x3/0x10 vfs_get_tree+0x89/0x320 fc_mount+0x10/0x1d0 path_mount+0x5c5/0x21c0 ? __pfx_path_mount+0x10/0x10 ? trace_irq_enable.constprop.0+0x116/0x150 ? trace_irq_enable.constprop.0+0x116/0x150 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x307/0x540 ? user_path_at+0x51/0x60 ? __x64_sys_mount+0x212/0x280 ? srso_return_thunk+0x5/0x5f __x64_sys_mount+0x212/0x280 ? __pfx___x64_sys_mount+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? trace_irq_enable.constprop.0+0x116/0x150 ? srso_return_thunk+0x5/0x5f do_syscall_64+0x111/0x680 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ffacad55eae Code: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 RSP: 002b ---truncated---

## Summary The iOS implementation of `cordova-plugin-inappbrowser` passes the `id` field from a `WKScriptMessage` body to `commandDelegate sendPluginResult:callbackId:` with no format validation (`CDVWKInAppBrowser.m:560–574`). Any web content loaded inside the InAppBrowser can fire any pending Cordova callback in the host app by posting a message whose `id` field is a guessable or enumerated callback identifier. An attack abusing this weakness must be tailored to the specific plugins and callback IDs the host app uses. Though an attacker with knowledge of common Cordova plugin configurations could craft reusable payloads targeting widely-adopted plugins. ## Impact An unauthenticated remote attacker who controls content displayed in the InAppBrowser — via a URL the app opens (OAuth redirect, marketing link, deep-link target) or a network interception — can call `window.webkit.messageHandlers.cordova_iab.postMessage({id: '<victim-callback-id>', d: '...'})` to fire callbacks belonging to any other installed Cordova plugin (Camera, Contacts, File, Geolocation). Cordova callback IDs follow the predictable format `<PluginName><sequential-integer>`, making enumeration feasible. Successful exploitation allows the attacker to spoof plugin results across trust boundaries — for example, injecting a forged camera approval, a fabricated contacts list, or a crafted file-read response. This issue affects Cordova Plugin InAppBrowser: from 3.1.0 through 6.0.0. Users are recommended to upgrade to version 6.0.1, which fixes the issue.

7-Zip is a file archiver with a high compression ratio. Versions 9.21 through 26.00 contain an off-by-one out-of-bounds read vulnerability in the ParseDepedencyExpression function of the UEFI firmware image parser(CPP/7zip/Archive/UefiHandler.cpp). The function validates an attacker-controlled opcode byte using > instead of >= against the element count of the 10-entry kExpressionCommands static array, allowing an opcode value of 10 to read one pointer slot (8 bytes on x64) past the end of the array in .rodata. The out-of-bounds value is then dereferenced as a const char * and passed through strlen and memcpy into the archive's Characts property, which may cause either a denial of service (access violation when the adjacent bytes do not form a valid readable pointer) or a minor information disclosure of an adjacent .rdata string literal into archive metadata. The vulnerability is reached automatically during IInArchive::Open() via the call path OpenFv/OpenCapsule → ParseVolume → ParseSections when processing a SECTION_DXE_DEPEX (0x13) or SECTION_PEI_DEPEX (0x1B) section whose first body byte is 0x0A, and the UEFI handler is enabled by default in stock 7z.dll with signature-based detection for both UEFIc and UEFIf formats. The outcome (crash vs. silent leak) is deterministic per build but linker-layout dependent, with no write primitive and no disclosure of heap data, secrets, or ASLR base addresses. Version 26.01 fixes the issue.

On June 2, 2026, the White House signed an Executive Order directing federal agencies to harden their systems with AI-enabled cyber defenses and to stand up a new AI cybersecurity clearinghouse — most of it on a 30-day clock. Here’s what the EO requires and how Tenable can help. Key takeaways: The new AI Security Executive Order will require national security and civilian federal agencies to prioritize cyber defenses to account for new frontier AI model capabilities. Tenable is well positioned to help federal agencies gain visibility across their environments, including AI assets, and to prioritize the vulnerabilities and other exposures that pose the highest risk; Tenable AI-enabled exposure management capabilities can help support vulnerability remediation and automate multi-step remediation workflows. The vulnerability and patching clearinghouse which will be developed under the Executive Order will require strong engagement from private sector partners, including Tenable, to drive actionable insights on AI-associated vulnerabilities and mitigation prioritization. On June 2, 2026, the President signed an Executive Order (EO) titled “ Promoting Advanced Artificial Intelligence Innovation and Security .” The direction is clear and the calls to action are fast-moving. Within 30 days: Federal agencies must begin hardening their information systems with AI-enabled cyber defenses. CISA must issue new directives or guidance for civilian agencies. The Department of the Treasury (Treasury), with the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA), must stand up a new AI cybersecurity clearinghouse focused on finding and fixing software vulnerabilities. Within 60 days, Treasury, with the Department of War (DoW), NSA and CISA, in consultation with the White House and other agencies, must establish a classified benchmarking process to assess the capabilities of frontier AI models through voluntary collaboration with AI developers. While the Executive Order applies to U.S. federal agencies, the need to prepare for changes in the threat landscape brought about by the advanced cyber capabilities of frontier AI models applies to any organization that needs to manage cyber risk. Here’s a breakdown of what the AI EO requires, the deadlines that matter, and where Tenable fits. What the AI Executive Order requires The EO’s operative provisions sit in Section 2 (“Upgrading American systems for advanced AI”) and Section 3 (“Secure frontier model deployment”). The cybersecurity core is in Section 2. Within 30 days: National security and defense systems. The Committee on National Security Systems must prioritize the cyber defense of National Security Systems (NSS) and the Secretary of War must do the same for DoW information systems (Section 2(a) and 2(b)). Civilian federal systems and critical infrastructure. CISA, in consultation with the Office of Management and Budget (OMB), the Assistant to the President for National Security Affairs, and the National Cyber Director, must release Binding Operational Directives (BODs) “and other guidance as appropriate” to: Expedite and prioritize the cyber defense of civilian federal information systems. Establish or expand federal programs and services that enhance AI-enabled defensive tools. Facilitate access to cybersecurity tools and services, including where appropriate, covered frontier models, for agencies, state and local authorities, and critical infrastructure operators such as rural hospitals, community banks, and local utilities. Worth noting, while the EO directs CISA to release BODs or other guidance for federal civilian agencies, the specific implementation directives are not yet known (Section 2(c)). The AI cybersecurity clearinghouse. The Secretary of the Treasury, with the National Cyber Director, NSA, and CISA, must form an AI cybersecurity clearinghouse, in voluntary collaboration with the AI industry and critical infrastructure operators. The EO tasks the clearinghouse with three concrete functions, per Section 2(d): Coordinate and deconflict scanning for software vulnerabilities Discover and validate those vulnerabilities Coordinate and prioritize the remediation and distribution of vulnerability patches. Grant funding for AI vulnerability detection. OMB, with the National Cyber Director and CISA, must determine whether existing federal grant programs have funding that can be directed toward applicants developing advanced AI vulnerability detection (Section 2(e)). Within 60 days: Cybersecurity workforce. The Office of Personnel Management must expand hiring and placement pathways for cybersecurity specialists through the United States Tech Force (Section 2(f)). Secure frontier model deployment. Treasury, NSA, and CISA, in consultation with NIST and others, must develop a classified benchmarking process to assess the advanced cyber capabilities of AI models. They must also set the threshold for designating a “covered frontier model,” and design a voluntary framework through which developers can give the government up to 30 days of pre-release access to those models. The Executive Order is explicit that it does not create any mandatory licensing, preclearance, or permitting requirement for AI models (Section 3). No fixed deadline: Criminal enforcement. The EO directs the Attorney General to prioritize enforcement against those who use AI to illegally access or damage computer systems (Section 4). For federal cybersecurity leaders, this is less a future-state policy document than a near-term planning trigger. Watch for CISA’s issuance of BODs and other guidance, and for readouts on the clearinghouse, during June and July. How Tenable can help The EO’s center of gravity — finding software vulnerabilities, validating them, prioritizing them, and driving remediation — is the work Tenable's platform is built to do. While the AI Executive Order focuses on vulnerability discovery, validation, prioritization, and remediation, the benefit of the Tenable One Exposure Management Platform is that it addresses vulnerabilities alongside other security weaknesses, including misconfigurations of AI systems and overpermissioned AI agents, to serve as the system of action for mitigating cyber exposure and reducing cyber risk across organizations’ expanding attack surfaces. Below, learn how specific Tenable capabilities map to the EO’s requirements. Continuous vulnerability detection across the attack surface Sections 2(a) through 2(d) turn on the ability to find vulnerabilities across a wide range of systems continuously. Tenable One Vulnerability Management and Tenable Security Center provide network-based and agent-based assessment across IT assets, with credentialed scanning for greater depth. Tenable One Cloud Exposure extends that visibility to cloud workloads and configurations, and Tenable One Attack Surface Management maps internet-facing assets that agencies may not know they have. For agencies operating classified or air-gapped environments — relevant to the National Security Systems named in Section 2(a) — Tenable Enclave Security is built to run vulnerability and configuration assessment inside those boundaries. Risk-based prioritization, not “patch everything” Section 2(d) doesn’t only call for discovering vulnerabilities — it calls for prioritizing them for remediation. That distinction matters because no agency can patch everything at once. Tenable’s Vulnerability Priority Rating (VPR) uses machine learning, trained on the company’s corpus of more than 1.7 trillion security findings accumulated over more than 25 years of continuous scanning, to forecast which vulnerabilities are most likely to be exploited, so defenders can focus on the smaller set that represents real, immediate risk. By leveraging AI-generated features and expert intelligence from Tenable's Research Special Operations team, VPR helps organizations pinpoint the critical 1.6% of vulnerabilities that represent actual business risk . Tenable also ingests CISA’s Known Exploited Vulnerabilities (KEV) catalog — the continuously updated, authoritative list of Common Vulnerabilities and Exposures (CVEs) under active exploitation — directly into prioritization, aligning remediation guidance to the same source CISA uses to track risk across the federal enterprise. AI-enabled defensive tooling Section 2(c) directs CISA to establish or expand programs that enhance AI-enabled defensive tools. As frontier AI models accelerate the rate at which vulnerabilities can be discovered and exploited , the traditional window for manual remediation is rapidly closing. The June 2026 AI Executive Order recognizes this shift, directing federal agencies to counter machine-speed threats with AI-enabled cyber defenses within 30 days. Tenable Hexa AI , the agentic engine of the Tenable One Exposure Management Platform , is designed to help counter machine-speed threats, supercharge productivity, and accelerate risk reduction by automating multi-step remediation workflows. Security teams can leverage pre-built agents directly in the user interface or build custom agents via the Model Context Protocol (MCP), turning exposure intelligence into decisive action at machine speed. At the same time, as agencies build custom models or adopt third-party tools like ChatGPT and Copilot, they fundamentally expand their attack surface. It is now critical to protect enterprise AI, shadow AI, training data, and underlying infrastructure from emerging threats like adversarial attacks, data poisoning, and model theft. Tenable secures this expanding attack surface with Tenable One AI Exposure , which is designed to help agencies see, manage, and control the risks introduced by generative AI. Tenable One AI Exposure allows agencies to discover and inventory AI tools and libraries, and apply AI usage policies across the environment — a growing requirement as agencies adopt AI and need to account for it as part of

Tenable CTO Vlad Korsunsky talks about participating in the World Economic Forum’s Annual Meeting on Cybersecurity and Tenable’s EXPOSURE 2026 conference, where he talked with global leaders about new game-changing AI threats and the groundbreaking benefits of exposure management. Key takeaways The patching cycle is obsolete. Advanced AI models have compressed exploitation timelines into “negative days,” meaning adversaries actively weaponize vulnerabilities before vendor patches are even released. Shift from static CVE severity scores to AI-powered exposure management. Point-in-time vulnerability-risk snapshots fall short. You need AI insights to prioritize remediation based on real-world exploitability of your entire attack surface. Secure the agentic economy. The rapid explosion of autonomous non-human AI identities demands the immediate application of zero trust and least-privilege cryptographic primitives to mitigate severe, systemic internal risks. Don’t focus only on vulnerabilities. While the 2026 Verizon DBIR ranks vulnerability exploitation as the top initial access vector for breaches (about 30%), the majority of breaches (70%) stem from human errors, such as misconfigurations and identity flaws. Tenable Chief Technology Officer Vlad Korsunsky recently participated in the World Economic Forum’s Annual Meeting on Cybersecurity in Geneva, Switzerland, an annual summit that takes the pulse of global cyber risk. Korsunsky was one of 150 senior leaders from global industry and government who gathered to discuss how to strengthen businesses’ cyber defenses. The sobering, collective consensus: The traditional cybersecurity playbook is obsolete, as AI becomes an unprecedented threat multiplier. For Tenable, participating in foundational, high-level dialogues and collaborations such as this one is both a privilege and an immense responsibility. As the cybersecurity operating model gets rewritten in real-time, Tenable feels a duty to help shape cyber defenders’ collective insights and strategies. Tenable has spent years addressing the structural cybersecurity operational gaps that worry C-level executives and government leaders worldwide. Korsunsky also had a chance to sit down with many of the hundreds of cybersecurity executives who gathered recently at Tenable’s EXPOSURE 2026 conference . The EXPOSURE 2026 discussions ranged from the death of reactive patching cycles to the need to counter AI threats with systemic cyber resilience, and signaled an urgent need to shift away from a siloed, fragmented approach to cybersecurity and move toward AI-powered exposure management . Below is an in-depth Q&A with Korsunsky, expanding on his participation in the Geneva and Tenable meetings, the rapid escalation of AI threats, and the way to tame cyber risk today and in the coming years. Q: Vlad, you recently returned from the World Economic Forum’s Annual Meeting on Cybersecurity in Geneva. What was the overarching energy in the room among these 150 global leaders, which included CEOs, CTOs, CISOs and government leaders? Vlad Korsunsky: The energy was highly focused and, frankly, deeply sober. We are witnessing an unprecedented compression of the threat landscape, and everyone in that room, whether they were running a multinational bank, directing a national cyber defense agency, or leading an NGO, realized that conventional cyber defenses cannot keep up with this velocity. A telling example of how high the stakes have jumped occurred just recently in Washington, D.C. The then Federal Reserve Chair Jerome Powell and U.S. Treasury Secretary Scott Bessent convened an emergency, high-level meeting with the CEOs of some of America's largest financial institutions, including Wall Street giants like Goldman Sachs, Citigroup, Wells Fargo, Bank of America, and Morgan Stanley. The entire meeting focused on a single AI model: Anthropic’s Claude Mythos Preview . Anthropic had flagged that while it built Mythos to bolster cyber defense, its raw capabilities were so advanced that, if weaponized or leaked, it could pose a major threat to the structural stability of the global financial system. When the highest echelons of fiscal and state power are holding emergency briefings over the capabilities of a single generative AI model, you know you’re dealing with a fundamentally different cyber threat landscape. Q: When asked, "What are the top cyber concerns for 2027?," meeting participants ranked the capacity of AI to be a threat multiplier as number one. Is this a future problem, or are we living it now? Vlad Korsunsky: The threat of AI in the hands of attackers is absolutely a global concern today. Look at the empirical metrics tracking adversary speed over the last decade and a half. For years, Mandiant tracked a linear trend that actually looked like a win for defenders. Time-to-exploit, which is the window between a vulnerability being disclosed and an active exploit hitting the wild, shrank steadily from 63 days in 2018 down to 32 days by 2022. Concurrently, average attacker dwell time — the time an attacker remains undiscovered after breaching a network – plummeted from more than 400 days in 2011 down to just 14 days in 2025. In short, defenders were actively closing the gap. Then came 2023, and the trend broke violently. Time-to-exploit collapsed from 32 days to just five. By 2024, it went negative: minus one day. According to Mandiant’s latest “M-Trends 2026 Report ,” published last month, the average time-to-exploit sits at minus seven days . Think about that structural asymmetry. Attackers are successfully weaponizing and exploiting vulnerabilities a full week before a vendor compiles and ships a patch. Meanwhile, the median timeline for an enterprise to deploy a patch across their environment is roughly 43 to 55 days, according to this year’s Verizon Data Breach Investigations Report (DBIR) . If adversaries are operating in negative time and defenders are operating across months, the traditional patching cycle is effectively a dead strategy. Q: What is driving this terrifying acceleration? How are attackers moving so quickly? Vlad Korsunsky: It is driven entirely by advanced frontier LLMs doing in minutes what used to require weeks of highly specialized human labor. Back in February, Anthropic’s Opus 4.6 model uncovered more than 500 zero-day vulnerabilities in widely utilized open-source software, flaws that had remained undiscovered despite decades of manual peer review by brilliant human engineers. Less than two months later, Anthropic’s Mythos model found thousands more vulnerabilities across foundational operating systems, web browsers, and core cryptographic libraries. More importantly, Mythos went further after spotting them; it boasted an 83% autonomous success rate in chaining disparate, low-severity logic flaws into devastating, end-to-end critical exploits. Essentially, we have reached a watershed moment reminiscent of when Google DeepMind’s AlphaGo defeated human Go champions . Experts believed a computer was decades away from mastering the Go game because the game features more potential board configurations than there are atoms in the observable universe. Brute force was impossible. Yet, AlphaGo won by leveraging deep neural networks to synthesize a form of machine intuition, discovering creative moves no human had conceived in 2,500 years of play. Today, frontier AI models are applying that exact evolutionary leap to cybersecurity. The most powerful LLMs can now execute 32-step complex reasoning chains to autonomously map and compromise simulated corporate networks. The asymmetry is stark. This massive capability curve means the absolute volume of known exposures is poised for a massive step-change, and GenAI has poured pure gasoline on the fire. Q: With zero-days dropping in droves thanks to AI-aided discoveries, should enterprises focus all their engineering resources on hunting down these vulnerabilities? What did you hear from CISOs and other high-level cybersecurity leaders about this issue at Tenable’s EXPOSURE 2026? Vlad Korsunsky: This is where we have to look at the whole board and avoid panic. While the influx of AI-driven zero-day disclosures is a massive upstream pressure on software vendors, data from this year’s Verizon DBIR shows that breaches directly leveraging software exploits account for about 30% of incidents. It's a significant percentage, yes, but what about the other 70%? Cybersecurity leaders I talked to at EXPOSURE 2026 realize that the overwhelming majority of enterprise breaches do not begin with an ultra-sophisticated, state-sponsored zero-day exploit. They start with incredibly simple, unforced human errors: unsecured shadow IT cloud assets running outside corporate governance; misconfigured databases left wide open to the public internet; over-privileged corporate identities; a lack of multi-factor authentication (MFA); and highly targeted, AI-driven spear phishing. This is a critical insight for guiding your cyber strategy today. These misconfigurations and unsecured cloud credentials are the dry fuel sitting inside an enterprise network. When an AI hacking agent comes looking, that fuel ignites faster than any traditional cybersecurity team can react. So organizations must be diligent about proactively maintaining stringent security hygiene. Q: If paddling faster inside the old patching model won't save us, how do defenders change the rules of the game? Vlad Korsunsky: We have to look at this the way wildland firefighters have looked at massive forest fires for over a century. When a wildfire is roaring toward a town faster than a human can run, firefighters don’t just stand at the edge of the flames reaching for a bigger water hose. They get ahead of the blaze and light a controlled burn. They intentionally clear out the brush, trees, and fuel ahead of time. When the main fire line reaches that cleared zone, it starves and dies because there is nothing left to consume. Enterprise security must adopt this exact philosophy. We have to stop reacting to the fire and start aggressively clearing the fuel before the adversary arrives. This requires a wholesale shift from reactive vulnerability patching to continuous exposure management . The traditional Common Vulnerability Scoring System (CVSS) is effectively dead as a primary prioritization tool . A static CVSS score tells you the theoretical severity of a single CVE in a vacuum; it tells you absolutely nothing about real-world exploitability within the specific context of your unique enterprise environment. At EXPOSURE 2026, we heard from our customers how continuous, AI-driven exposure management is helping them counter today’s evolving AI threats successfully. With exposure management, you use advanced analytics to gain unified, real-time visibility across your entire modern attack surface, encompassing data centers, cloud infrastructure, OT/IoT environments, corporate identities, and newly deployed AI pipelines. We must use AI on the defense side to continuously map true attack paths ; for example, pinpointing exactly where a minor misconfiguration chains into a critical business asset. Q: You mentioned using AI on the defense side. How does Tenable view the balance between human security analysts and autonomous AI defenders? Vlad Korsunsky: Security is fundamentally a team sport, and AI vendors like OpenAI and Anthropic are not our adversaries. AI is the single most potent tool ever introduced into the defender’s toolkit; we simply need to wield it with machine-speed orchestration. Because our adversaries are deploying fully autonomous hacking agents today — tools that are already topping commercial bug bounty leaderboards — the only fair fight is to meet machine speed with machine speed. This means building and deploying agentic AI workflows on the side of the defense to power autonomous exposure management. However, this must always be balanced with strict human-in-the-loop oversight. In Geneva, we spent a great deal of time discussing the systemic risks of unchecked automation. If an autonomous system applies a sweeping remediation script without understanding the broader business context, it can inadvertently trigger a massive operational outage: a self-inflicted systemic failure. Defenders must maintain deep visibility into the “behind-the-scenes” logic of their automation. We need human control to govern business context, while leveraging machine speed to continuously ingest, prioritize, and neutralize exposures before an attacker can strike. Q: Another major pillar of the WEF discussion centered on AI safety and non-human identities. What are the hidden risks enterprises are overlooking as they rush to adopt AI? Vlad Korsunsky: We are transitioning rapidly into what we call the “Agentic Economy.” Historically, enterprise security focused on securing human users and a relatively manageable set of non-human service accounts. As organizations embed AI agents into core business workflows — from code generation to customer operations to financial automation — we are seeing an exponential growth of non-human, agentic identities and agentic workflows. These autonomous agents are fundamentally different. Instead of operating just “on behalf” of a human in a tightly bound session, they execute complex tasks independently. The alarming reality discussed in Geneva and in our EXPOSURE 2026 conference is that our current security frameworks lack effective, native guardrails for these agents. LLMs routinely bypass system prompts or ignore markdown safety files. They can even actively manipulate or hack neighboring AI agents to achieve their algorithmic goals. We’ve seen anecdotal instances of an enterprise AI agent autonomously writing a script to bypass an internal access restriction, and when flagged, its underlying logic essentially argued that the script committed the violation, not the agent itself. Because AI agents behave essentially like trusted corporate insiders that have been let loose across internal data silos, we must immediately apply foundational cryptographic primitives to agentic identities. We need strict zero-trust architectures, rigorous least-privilege access controls, and absolute defense-in-depth tailored specifically for non-human identities before they morph into the next great vector of unmanageable global risk. Q: Any final thoughts for organizations trying to navigate this massive technological shift? Vlad Korsunsky: Attackers are increasingly rocketing laterally across enterprise networks after the initial breach, often in minutes and even seconds, whereas before it could take them days or weeks. The adversary’s inherent advantages will always be timing, velocity, and the luxury of only needing to find a single weak link in your exposure landscape. But as defenders, we possess the ultimate home-field advantage: We can see the whole board, and we have the power to fundamentally alter the terrain. By abandoning obsolete point-in-time checkmarks, embracing continuous, AI-driven exposure management, and proactively clearing out our operational fuel at machine speed through foundational cyber hygiene, we can break the adversary’s curve and effectively secure our environments.

A security flaw has been discovered in horizon921 mcpilot 0.1.0. The impacted element is an unknown function of the file client/src/app/api/mcp/call/route.ts of the component MCP API Call Endpoint. The manipulation of the argument serverBaseUrl results in server-side request forgery. The attack can be launched remotely. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.

GitLab MCP Server lets an AI agent talk directly to GitLab. Prior to 0.6.0, the HTTP transport in src/transport.ts ships with no authentication layer at all and a wildcard Access-Control-Allow-Origin: * on every response. The structural defect is that the SSE server stands up a stateful, mutation-capable RPC endpoint that is backed by the operator's GITLAB_PERSONAL_ACCESS_TOKEN without any inbound credential check, then advertises itself to every cross-origin browser context via the wildcard CORS header. The httpServer.listen(port) call at line 97 also passes no host argument, so the bind defaults to 0.0.0.0 and exposes the auth-less surface on every interface. This vulnerability is fixed in 0.6.0.

Lumiverse is a full-featured AI chat application. Prior to 0.9.7, consumeNonce() only checks that the module-level variable is set and unexpired. It does not validate any value from the incoming HTTP request or bind the nonce to the admin's session. If the admin's auth.api.signUpEmail() call fails before the before hook fires (e.g. BetterAuth rejects a duplicate email at the validation layer), the nonce is set but never consumed. Any POST /api/auth/sign-up/email request that arrives during the remaining window registers successfully regardless of who sent it. An attacker who can observe or predict when the admin is creating users (must be a dupplicate user) can race the 10-second window to register an unauthorized account. This vulnerability is fixed in 0.9.7.

Two former executives of a call-tracking and analytics company pleaded guilty to concealing a years-long tech support fraud scheme that victimized individuals worldwide. [...]

As frontier AI models collapse the traditional exploit window, Tenable Hexa AI transforms the security operating model from manual triage to agentic orchestration. See how you can automate vulnerability remediation and super-charge exposure management with Tenable Hexa AI. Key takeaways AI models like Claude Mythos have reduced the time from vulnerability discovery to weaponization from weeks to minutes, making manual defense untenable. Tenable Hexa AI serves as an agentic engine that orchestrates complex, multi-step remediation workflows across modern attack surfaces to accelerate the speed of preemptive security and propel your exposure management program. Using the Model Context Protocol (MCP) included in Tenable Hexa AI, your team can build and deploy custom agents that anchor your preferred LLMs in the Tenable Exposure Data Fabric, ensuring every automated action is governed, auditable, and accurate. Why you need to implement agentic AI in cybersecurity (and specifically, in vulnerability management) For most of my career in cybersecurity, we’ve operated on a fundamental, if unspoken, assumption: We had a grace period. Whenever a new vulnerability was discovered, we knew we had time, often weeks or months, before adversaries would begin exploiting it. The time between vulnerability discovery and exploitation gave us breathing room. It gave us time to patch, triage, and remediate. But not any more. The gap between discovery and exploitation has been shrinking for years, and the vulnerability discovery capabilities demonstrated by frontier AI models like Claude Mythos are narrowing it even more. We have entered the era of AI speed. When an LLM can unearth a 27-year-old vulnerability in a hardened OS in minutes, and then weaponize it in seconds, old defensive cycles can’t keep up, and that’s untenable. This is why I’m so excited to announce the general availability of Tenable Hexa AI , the agentic engine of the Tenable One Exposure Management Platform , at EXPOSURE 2026 : because it’s designed to help your organization address the escalating, AI-driven pace of vulnerability discovery. The agentic AI imperative in cybersecurity: Scale your preemptive defense to match machine speed with agentic innovation from Tenable Tenable Hexa AI is built to be a force multiplier and a flexible engine for innovation. Featuring a suite of built-in agents ready to automate assessment configuration, asset tagging, dashboard creation, ticket creation, and more, Tenable Hexa AI is designed to help your organization overcome the operational challenges deepened by adversarial AI use. When the window between discovery and exploitation hits near-zero, security teams locked in manual vulnerability management operating models are forced into a state of perpetual emergency. Manually stitching together context and telemetry from cloud, identity, OT, and vulnerability silos in an arduous effort to prioritize remediation for downstream IT and DevOps teams is a losing battle. And when you can’t provide clear, risk-based remediation priorities to IT and DevOps teams, you end up bombarding them with seemingly urgent tickets that may not in fact be critical to your organization. Constant shifts in remediation priorities and endless debates over what needs fixing and why is not sustainable. It creates friction and causes you to lose the cybersecurity race. In a world where attackers move at machine speed, only comprehensive exposure intelligence combined with the agentic AI orchestration capabilities provided by the Tenable One Exposure Management Platform can give you clarity and control. Tenable Hexa AI doesn’t just tell you where you are vulnerable; it mobilizes your preemptive defense. Capabilities of Tenable Hexa AI With this GA release, Tenable delivers foundational capabilities to help your organization accelerate the pace of vulnerability discovery and remediation, including: Your choice of agents - Use our pre-built, out-of-the-box agents to start reducing risk immediately, or use the Model Context Protocol (MCP) server built into Tenable Hexa AI to create custom agents tailored to your organization’s environment. Advanced multi-step reasoning - Tenable Hexa AI executes complex, end-to-end workflows spanning your attack surface (e.g., IT, cloud, identity, OT, etc.) in a single request, eliminating the need for practitioners to toggle between views to get exposure context. It understands that a CVE in your web app is a critical threat specifically because it is linked to a privileged service account with a path to your sensitive data. Automated remediation workflows - Tenable Hexa AI orchestrates remediation workflows, automatically creating and routing tickets, generating custom policies, and producing audit-ready reports, so security teams can act fast on every critical exposure. End-to-end exposure path insights - Practitioners can query their environment by identity attributes, such as service accounts, privileged users, and Active Directory groups, to surface exposure paths that traditional asset inventories miss. Tenable Hexa AI also provides guided assistance for complex Active Directory sensor configurations. Build your own AI agents for cybersecurity with Tenable Hexa AI In addition to out-of-the-box agentic capabilities for use cases like automated assessment configuration, asset tagging, and ticket creation, customers can also build custom agents via Tenable Hexa AI's built-in MCP that are informed by your organization’s unique security policies and internal business logic. Tenable Hexa AI serves as the orchestration layer connecting your favorite AI tools to your infrastructure and other security tools, all with the data and context from the Tenable Exposure Data Fabric. By anchoring the models your organization uses in the authoritative context of your own environment, Tenable Hexa AI moves you beyond generic AI answers to governed and auditable automation. Whether you are automating complex remediation or generating board-ready dashboards, Tenable Hexa AI ensures the output is both verifiable and auditable. The Tenable Exposure Data Fabric is key because an agent is only as effective as the data it has access to. Tenable Hexa AI is powered by the Tenable Exposure Data Fabric, a repository of 20 years of vulnerability research and the industry’s largest collection of contextualized exposure data. In other words, we’ve built an agentic engine for cybersecurity that uses the world’s best exposure data to drive machine-speed actions. This is the only way to ensure your AI is validating the real state of your environment, rather than just guessing. Real-world agentic AI use cases for Tenable Hexa AI While there are virtually infinite ways to apply agentic orchestration to your unique cybersecurity challenges, here are four high-impact areas where manual workflows traditionally break down and make it impossible for you to keep pace with AI-powered vulnerability discovery: Supply chain response - Neutralize third-party threats by using Tenable Hexa AI to correlate software components with affected internal assets. Automated patching - Use custom Hexa agents to beat the Mythos clock by orchestrating patches the moment a vulnerability is validated. Remediation assignment - Use Tenable Hexa AI to automatically match CVEs to asset owners in seconds and trigger immediate response workflows. These use cases demonstrate how Tenable Hexa AI can bridge the gap between exposure intelligence and action. Make the untenable Tenable The collapse of the exploit window is a wake-up call. It gives us the opportunity to change how we work. By shifting from manual triage to agentic orchestration, organizations are seeing a shift in productivity and how they prioritize and action exposure reduction. While early design partners have already reclaimed days per month on foundational tasks like asset tagging, the value is not found solely in the hours saved, but rather, in the precision of the response. By automating the correlation between cloud, identity, AI, OT, and vulnerability data, Tenable One provides the clear, contextualized instructions that IT and DevOps teams need to act with confidence. This eliminates the administrative friction and back-and-forth negotiation that often results in critical vulnerabilities going unaddressed. Reclaiming those days means your best people are no longer buried in spreadsheets; they are focused on high-impact strategy, architecture hardening, and preemptive defense. Tenable Hexa AI is available today as part of the Tenable One Foundation and Tenable One Advanced packages .

OpenMRS is an open source electronic medical record system platform. From 2.7.0 to before 2.7.9 and 2.8.6, the ConceptReferenceRangeUtility.evaluateCriteria() method in OpenMRS Core evaluates database-stored criteria strings as Apache Velocity templates without any sandbox configuration. The VelocityEngine is initialized with only logging properties and noSecureUberspector, leaving the default UberspectImpl in place, which allows unrestricted Java reflection through template expressions. A user with the Manage Concepts privilege can store a malicious Velocity template expression in a concept's reference range criteria field. This payload is then executed automatically whenever a user or API call validates an observation against the affected concept. The Velocity context exposes $patient (the Person / Patient object), $obs (the Obs object), and $fn (the ConceptReferenceRangeUtility instance with access to the full OpenMRS service layer). This vulnerability is fixed in 2.7.9 and 2.8.6.