If you find any vulnerabilities, it would be great if you could report them privately to security@edx.org – we have a process for reaching out to deployers ahead of publicly releasing a fix so that they have time to deploy the fix themselves. (Coordinated disclosure, essentially.) You can see edX’s responsible disclosure security policy here: https://www.edx.org/policy/security
The example you provide isn’t exploitable, even by an attacker with the ability to run a limited set of management commands, since the list of table names is hardcoded in the script and can’t be modified by command line arguments. But, it’s still a weakness, since theoretically the script could some day be modified to accept that dictionary as CLI input—and we should avoid having any code that constructs SQL from string concatenation. So this example is one where I’d personally be comfortable with you just submitting a PR, which could then be routed to the appropriate team for review. It’s not only non-exploitable in practice, but would require privileged access or a nonstandard configuration on top of that. (Vulnerabilities that require privileged access are sometimes still vulnerabilities. For example, if someone could run arbitrary code on the backend by accessing a Django server’s admin pages, that would be a problem and we’d want to know about it. Users of admin pages may only be given limited access to some models, after all.)
So I’d say use your discretion. If something looks like it’s just causing false positives due to poor coding practices, a PR would be great, but if you think it’s possible it could be exploited then an email to security@edx.org would be best. Either way, it’s appreciated!
.