When we find a security-relevant defect in one of our own products, we publish it here — with the commit that fixed it, the versions it affected, why we rated the severity the way we did, and what the fix does not cover. Each advisory has a permanent URL and a stable identifier, so it can be cited, linked and checked against the source.
This is a self-issued vendor track. Every entry traces to a commit in a repository we control, and the commit hash is on the page. You can read the diff yourself: the MoorAI agent is open source under AGPL-3.0.
No CVE has been requested or assigned for any advisory here. Identifiers on this page are vendor-assigned and follow the form MOORAI-YYYY-NNN. They are ours, they are not CVE identifiers, and they carry no authority beyond this site.
We publish no third-party vulnerability research. Nothing here is a finding against another vendor's product. If that ever changes, it will be published under a coordinated-disclosure timeline with the affected vendor named and their response quoted, and it will say so plainly.
We have also not been through an external penetration test or an independent security audit. When one happens, it will appear on the trust page with its scope and its report.
Newest first. 1 published. Every one is a defect in our own product that we found and fixed; each links to the commit that fixed it.
| Identifier | Advisory | Severity | Status |
|---|---|---|---|
| MOORAI-2026-001 | Inbound WebFetch and WebSearch content was never scanned The outbound request was scanned. The page that came back was not — and that is the delivery path for indirect prompt injection. | Medium | Fixed and released in 0.79.0 |
One route, one address, and a human reads it. We would rather hear about a problem badly written than not hear about it.
Email gitayg@gmail.com with Security report in the subject line. This is the same address published in our security.txt and in the site footer. If you would rather not use email, the contact form reaches the same person — send a short note and we will move to email from there.
Whatever you have. The things that help most:
moorai --version.We do not publish a PGP key today. Saying otherwise would be worse than saying nothing — an unmaintained key is a dead drop. If a report needs encrypted transport, send a first message with no technical detail in it and we will agree a channel before you send anything sensitive. If we publish a key later it will appear in security.txt under Encryption.
English or Hebrew. Write in whichever you are more precise in — a clear report in Hebrew beats a vague one in English. Machine-translated reports are fine; we will ask if something is ambiguous rather than guess.
These are the commitments of a small team, written at the size we can actually keep. If we are going to miss one of these dates, you will hear that from us before the date, not after it.
A human reply confirming we have the report and can reproduce it, or asking for what we need in order to try. Not an auto-responder.
Whether we consider it a vulnerability, the severity we are assigning and why, and a target date for the fix. If we disagree that it is a vulnerability we will say so with our reasoning, and you are free to publish that reasoning alongside your own.
90 days from acknowledgement is our target for a released fix. Where a fix lands sooner we will publish sooner. Where it will take longer we will tell you why and agree a date with you rather than let the clock run out quietly. When the fix ships, it gets an advisory on this page with an identifier, the affected range and the commit.
Every advisory carries a credit line. Yours will say whatever you want it to say — a name, a handle, an organisation, or nothing at all. You choose, and we will show you the wording before it goes up.
We ask that you give us 90 days, and we will ask for an extension if we need one. We will not ask you to sign anything to receive an answer, and we will not treat a published finding as a breach of anything. If you publish before we have fixed it, we would rather you told us the date than surprised us.
We do not run a paid bug bounty and do not want to imply one. What you get is a fast human answer, a fix, and public credit in the wording you choose.
In scope: the MoorAI agent and console, AppCrane, Productizer, IT-AI, and this website. Anything on a glick.run hostname, and any repository under github.com/gitayg.
Out of scope, because reporting them costs you time and gets you nothing: findings that only restate a limit we already publish (the methodology page lists ours, and every advisory here has a “what the fix does not cover” section); missing hardening headers with no demonstrated impact; automated-scanner output with no working proof of concept; denial of service by volume; social engineering of us or our users; and anything that needs physical access to a machine.
Please do not test against anyone else's data. The MoorAI agent runs on the endpoint and is open source — test against your own install. If a test would touch a real customer's device, tenant or console data, stop and tell us what you intended to do instead; we will help you set up a way to prove it safely.
If you research in good faith under this policy, we will treat your work as authorised. Concretely: we will not bring or support a legal claim against you over the research, we will not report you to law enforcement over it, and we will not treat it as a violation of our terms of service or our licences.
“Good faith” means you stay within the scope above, you stop as soon as you have proved the point, you do not access, alter, destroy or keep data belonging to anyone else, you do not degrade a service anyone is using, and you give us the reporting window before publishing.
Two honest limits on that. This protection is ours to give and only ours — it cannot cover a third party whose systems your testing touches, including any host or platform we run on. And if you go outside good faith as described here, it does not apply. If you are unsure whether something is inside the line, ask first: gitayg@gmail.com. Asking has never cost anyone anything.
An identifier reads MOORAI-YYYY-NNN: the product, the year we published, and a counter that starts at 001 each year. It is assigned when the advisory is published, not when the bug is found, and it never changes or gets reused.
This is not a CVE and does not become one. CVE identifiers are assigned by CVE Numbering Authorities; we are not one, and we have not requested an identifier from one. If a CVE is ever assigned to something on this page, the advisory will show it next to our identifier and the difference will be marked. Until then, an advisory here saying “no CVE assigned” is stating a fact about the world and not a formality.
Machine-readable pointers to this policy live in /.well-known/security.txt, per RFC 9116.
Advisories on this page describe defects in our own products, found by us and fixed by us. Identifiers are vendor-assigned and are not CVE identifiers; no CVE has been requested or assigned for any entry. Version ranges refer to the MoorAI agent's own releases. Where an advisory says a fix is committed but not yet released, that is the state at the time of writing and the status line on the advisory says so. Response times on this page are commitments, not a contractual service level.