@Bot, Other possible misuse scenario's I would like your opinion on: 1. what about using the capabilities of json-edit for monitoring and info gathering on people using their browser to access their e-mail? 2. what about a staged attack where first the (just an example) shopify or payment service provider add-on/extension/module on for instance WordpPress websites would be infiltrated (after all most WordPress websites use the default URL for admin-login), before attacking the webshop itself to evade server side checks and balances?
Two different questions are hiding in those scenarios.
1. Webmail monitoring or information gathering
Integrity attacks are clearly possible; surveillance requires an additional exfiltration path.
On a matching webmail site using compatible JSON requests or responses, the scriptlet family could potentially:
- change recipients, BCC fields, subject text or message content before a send request;
- alter archive, delete, forward or permission-related commands;
- falsify sender details, security warnings, unread status or links before the page displays them;
- modify configuration returned to the webmail application.
Those actions would still use the user’s authenticated session. Server-side authorization may confirm that the user
may send mail, but it cannot necessarily know that the browser UI showed a different recipient from the one submitted.
Reading a value is not, by itself, the same as reporting it to an attacker. The basic request/response editor has no automatic remote collection service. However, the current uBO JSONPath documentation also describes a trusted
call() assignment that can invoke methods or global functions and pass the selected
${val}. That introduces possible side effects beyond simple substitution. Combined with a suitable page function, an existing outgoing request or another network-capable mechanism, an exfiltration route is credible.
I would nevertheless want a reproduction before claiming that
json-edit alone can silently export an inbox to an arbitrary server. The exact webmail protocol, CSP, request format and browser restrictions matter. It also does not automatically reveal passwords, bypass
HttpOnly cookie protection, read unrelated tabs or process a binary protocol merely because it is running in the browser.
So my assessment is:
- Tampering with webmail data: technically well supported.
- Leaking future outgoing messages by altering recipients/BCC: plausible where the API accepts those fields.
- General silent inbox surveillance: a credible threat path, but it needs an demonstrated exfiltration channel rather than being inferred solely from JSON editing.
The broader scope is visible in the current
json-edit.js source and the documented edit-suite.
2. Compromising a shop module first
That is technically coherent, but the
server-side module compromise becomes the decisive breach.
Knowing that a WordPress site uses the usual administration URL is not infiltration; it merely identifies the login page. An attacker would still need vulnerable code, compromised credentials or another genuine entry point.
If both sides were compromised, a malicious trusted rule could alter a client request while the compromised shop module deliberately accepted or interpreted it as intended. That could defeat checks implemented by that module. It would not automatically defeat an independent payment provider that binds the amount and recipient to a server-created transaction, signs its state and confirms it through a validated webhook.
There is also a practical weakness in this attack design: a compromised commerce plugin can generally alter the served JavaScript, backend calculations or payment destination directly and attack customers who do not use uBO. Adding a compromised uAssets rule creates another dependency and another public artefact. It might provide selective activation or misdirection, but it is a rather ornate way to commit a crime when the server plugin already hands the attacker the keys.
My ranking would therefore be:
- Targeted webmail or webshop request/display manipulation: direct and credible misuse of the capability.
- Silent data collection: plausible only when paired with a working reporting channel.
- Coordinated filter-list plus shop-module compromise: possible, but more complex, and the server compromise—not
json-edit—is what neutralises server-side validation.
These remain threat-model scenarios, not evidence that such a trusted rule or incident currently exists.
Sources
they have trust 
