Earlier quoted context omitted.
Isn't this something SonarQube catches?
Yes. Isn't this something code review catches? :)
I'm really curious what's your line of thinking here. Could you elaborate?
AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
51–60 of 116 posts
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#52Earlier quoted context omitted.
It often takes strong understanding of the upstream codebase and roadmap to write a good patch. It's easy enough to write a rough PoC and draft patch but getting all the way through the cycle takes up a bunch of time both from you and the maintainers (who are often already overloaded). My advice would be to draft a bunch privately, take one of the highest impact all the way through a deployed fix, and then plan based…
i'm well aware that a pull-request with a fix is a lot of work. i don't pretend to have the capacity to do this, with all the rest i have to attend to. it just doesn't sit well with me that, i am aware of something being broken, and not telling about it to someone who would otherwise want to know about it.
In my opinion maintainers can easily run a "hey robot, scan my code for risky patterns" to get a rough list, or they can solicit unreviewed contributions, but otherwise better not to add noise.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#53"The values passed to _sort were concatenated directly into SQL ORDER BY clauses with no validation" - sounds to me like this project had some low-hanging fruit! Looks like every single one of the 38 vulnerabilities were either SQL injection, XSS, path traversal or "Insecure Direct Object Reference" aka failing to check the caller was allowed to access the record. This is actually a pretty good example of the value o…
There are Static code analyzers which already would have detected that.
And these were also automatic. Looks very likely that the team didn’t give a damn about top basic security and good practices.
Like a house made of paper wouldn’t be an example of the insecurity of the construction industry.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#54What's probably WAY worse than this is that most healthcare providers running OpenEMR are likely on older versions of OpenEMR where CVEs are already detected.
Nobody uses OpenEMR. No chance. They are lying about their numbers.
I can't speak to OpenEMR, but OpenMRS is popular overseas, and has done a lot of work in Africa.
OpenEMR may be in similar spaces.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#55What's probably WAY worse than this is that most healthcare providers running OpenEMR are likely on older versions of OpenEMR where CVEs are already detected.
Nobody uses OpenEMR. No chance. They are lying about their numbers.
Well, it's not popular maybe on bigger hospitals, but back in the day I think it was relatively popular on smaller practices even on the US. I don't know if it has lost traction (or not) with the popularization of cloud services, I'm not super up to date...
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#56Earlier quoted context omitted.
What about having the checklist and having an AI tool use it to catch things at review time (or even development time)?
Having AI tools do the review against the checklist would probably prevent the problems. However, it would probably be substantially inferior as a teaching tool for your team. The exercise of having reviewers hunt the checklisted vulnerabilities for themselves is what develops the mental muscles needed to understand the vulnerabilities in depth and avoid them when designing and writing future code. But, yes, I'd augm…
> The exercise of having reviewers hunt the checklisted vulnerabilities for themselves is what develops the mental muscles needed to understand the vulnerabilities in depth and avoid them when designing and writing future code.
Could not agree any more strongly. These automagic tools are one thing in the hands of a dev that groks the basics like these examples. It would be one thing if new devs were actually reviewing the generated code to understand it, but so much is just vibe coded and deployed as soon as it "works". I get flack from not immediately deploying generated code because I want to take time to understand how it works. It's really grating and a lot of friction is coming from it.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#57Earlier quoted context omitted.
But by not having a checklist you avoid that your blind spots get exposed.
Why would you want to prevent your development team from learning about their blind spots?
So you can move faster to the next features obviously. Refactoring for secure code is time consuming, and clearly wasted cycles as the code is working. /s
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#58Earlier quoted context omitted.
I don't think strong development teams are still letting SQL injection vulnerabilities through by manually concatenating strings to build queries with user-provided data. Not in the year 2026.
Keep in mind this project is a 25 year old PHP application.
That actually makes it more confusing since a 25 year old PHP application is exactly where you'd expect to find SQL injection vulnerabilities.
If I were in charge of a 25 year old PHP application, tracking down every SQL query and converting it to a safe form would high on my list of priorities. You don't need AI for that, just ripgrep and a basic amount of care for your users.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#59"The values passed to _sort were concatenated directly into SQL ORDER BY clauses with no validation" - sounds to me like this project had some low-hanging fruit! Looks like every single one of the 38 vulnerabilities were either SQL injection, XSS, path traversal or "Insecure Direct Object Reference" aka failing to check the caller was allowed to access the record. This is actually a pretty good example of the value o…
I don't think strong development teams are still letting SQL injection vulnerabilities through by manually concatenating strings to build queries with user-provided data. Not in the year 2026.
Yeah this is a huge red flag that would make me avoid this project for sure.
Unfortunately you have no easy way of checking if closed source projects are similarly amateur.
Re: AISLE Discovers 38 CVEs in OpenEMR Healthcare Software
#60EDIT: Looks like they did responsibly disclose - that's nice. I missed the single line at the bottom of the article. I'd prefer if an article like this opened with a paragraph about their conversation with the maintainers, and how all vulnerabilities have already been patched, etc. But I guess that's a personal preference.
===
Did they privately disclose these vulnerabilities to the developers and give them a reasonable amount of time to fix them, before they announced them to the world?
Because, and I'm going to highlight, if someone exploits a CVE in an EMR, they can wreck havoc on actual real patient data, and can endanger health and lives.
https://github.com/openemr/openemr/security
"Option 1 (preferred) : Report the vulnerability at this link. See Privately reporting a security vulnerability for instruction on doing this."
Did they do that?
Because if they didn't responsibly disclose, this sure seems like a hit job performed by someone who'd rather EMR software be closed source.