1) routing (mis-)config problem - key of remote exploit. This should always be something people double check if they don't understand how it works.

2) hard-coded secrets - this is just against best practice. don't do this _ever_ there's a reason secure enclaves exist, not working it into your workflow is only permissible if you're working with black-box proprietary tools.

3) hidden user - this is again against best practice allowing for feature creep via permissions creep. If you need privileged hidden remote accessible accounts at least restrict access and log _everything_.

4) ssrf - bad but should be isolated so is much less of an issue. technically against best practices again, but widely done in production.

5) use of python eval in production - no, no, no, no, never, _ever_ do this. this is just asking for problems for anything tied to remote agents unless the point of the tool is shell replication.

6) static aes keys / blindly relying on encryption to indicate trusted origin - see bug2, also don't use encryption as origin verification if the client may do _bad_ things

parsing that was... well... yeah, I can see why that turned into a mess, the main thing missing is a high-level clear picture of the situation vs a teardown of multiple bugs and a brain dump

>if they don't understand how it works.

The problem quite often is they think they know how it works, Dunning-Kruger effect and all.