aejo is at v0.1.0. only the current release receives fixes.

don't open a public issue. email akali11112001@gmail.com with subject [aejo security] <short title> and the following body:

1. what you found (one paragraph)
2. how to reproduce (steps or a small repro repo)
3. potential impact (worst-case, attacker capability assumed)
4. your suggested mitigation, if any
5. whether you want public credit and what name/handle to use

we'll acknowledge within 72 hours and aim to ship a fix within 14 days for high-severity issues. for lower severity, expect a fix in the next minor.

• secret leakage — if a flag's msg field could echo back a token, email bound to a private setting, or any credential, that's in scope
• scope escalation — if there's a path through aejo to make a write call using a read-only token, that's in scope (we believe there isn't but happy to be proven wrong)
• denial of service via crafted github responses — if a particular json shape from /users/<login> can cause aejo to hang, oom, or loop, that's in scope
• rate-limit footgun — if a default code path makes more api calls than the documented ~10/login budget, that's in scope

• "aejo gave a wrong verdict on account X" — open a normal issue with the scan output and the actual ground truth. that's a calibration bug, not a security bug.
• "i ran aejo against an account that doesn't exist and it errored" — yes, it does, on purpose
• "i hit the github rate limit" — set GITHUB_TOKEN
• vulnerabilities in @octokit/rest, chalk, pino, or other deps — please report those upstream and we'll bump the version once they ship

reporters who file in-scope, reproducible issues get listed in CHANGELOG.md under the release that contains the fix, unless they opt out.

aejo's runtime needs zero write scopes on the target. if you're operating aejo yourself, generate a fine-grained PAT with public_repo and read:user only. giving it more is harmless (aejo ignores them) but unnecessary.