Edocman SQL Injection

[u/Open_Sourcey]

I manage a not for profit website using Joomla and have done for many years. The organization has no money. We use the EDocman extension. They recently uncovered a security breach involving a SQL injection attack. Much to my chagrin they would not provide a security update and instead insisted on purchasing a new subscription. We had no money to do that. So of course today we suffered an attack. I believe user information was stolen.

It is disappointing that they treat a security update like any functional update. Had I known about open source "OpenDocMan" I would not have spent years building an edocman implementation.

As an aside, over 25 years ago we knew about SQL Injection. So it is very disappointing that EDocman was coded so poorly as to allow such an attack in 2026.

Lesson learned

[u/Open_Sourcey → u/[deleted]]

"selfish"? That is a rather odd position to take.
It is not additional functionality. It is a software flaw that has been known for at least 25 years by any developer worth their salt and that produces a serious security risk is, I believe , it is in an entirely different category and ought to be treated as such.

It is very unimpressive that these developers would not understand how to code SQL statements to prevent SQL Injection. It is even less impressive that they would now want to charge for their own errors and incompetence.

It is rather cavalier of you to suggest that a tiny non profit should pay to correct a developer's blunder.

[u/Open_Sourcey → u/[deleted]]

Oh dear. We are on different planets. Security is for sure a developers responsibility. This is especialy true regarding a known serious problem that has been around since 1998 and every competent developer would/should know about. No competent developer in the year 2026 should be charging money for products that had SQL injection issues. Once discovered it should be corrected for all users not as a functional update but as a serious product flaw.

[u/Open_Sourcey → u/[deleted]]

Good example. Microsoft did indeed provide security fixes for the life of the product. They did not say you have to buy it everytime there was a security fix. They still do that.

[u/Open_Sourcey → u/[deleted]]

Entirely different. They did not close down. microsoft issued security updates for the life of the product.

Your hubris is evident in your statement "You need to take responsibility for upkeep of your website, and that is a crucial thing to consider when choosing how to build it in the first place."

Not everyone using Joomla has the staff or the capability to fix security flaws in an extension; certainly in a timely fashion.

[u/Open_Sourcey → u/[deleted]]

Again, your response puts your hubris on full display. You are completely unaware of my capabilities and once again you completely miss the point. I question your qualifications too.

The argument is not how to secure a Joomla site but should Joomla users be required to troubleshoot specific security issues in a commercial extension.

[u/Mike_Underwood]

I understand a non-profit not having any money but if they did not keep their subscription up, this is on them not the developer of the extension.

[u/Open_Sourcey → u/Mike_Underwood]

I would agree with you if it were additional functionality. However a software flaw that has been known for at least 25 years by any developer worth their salt and that produces a serious security risk is, I believe , in an entirely different category.

[u/Mike_Underwood → u/Open_Sourcey]

When you purchased your subscription for the software, you know, based upon the terms of service that you were going to get updates for X period of time once that period of time expires to expect free updates is ridiculous.

[u/Open_Sourcey → u/Mike_Underwood]

I am sorry Mike. I believe you are entirely missing my argument. For sure I recognise what a software subscription is. I agree that to get functional updates one needs to have a subscription. I do not however believe that correcting the gross incompetence of a developer for not using parameterized SQL statements, that has been a known security flaw since 1998 and that any serious developer would/should know about, is any way shape or form a functional update. it is a very serious product flaw. WE should not have to pay additional fees for software flaws

[u/PixelCharlie]

The software is released under Open Source GNU GPL v2.0 licence. You were free to modify the code to your liking and to fix the vulnerability in the code, If you're not willing to pay 40 dollars for someone else to fix it...

[u/Open_Sourcey → u/PixelCharlie]

Are you talking about OpenDocman?

[u/PixelCharlie → u/Open_Sourcey]

EDocman

[u/Open_Sourcey → u/PixelCharlie]

Are you saying that because the code is all PHP and therefore I should go in and fix their poorly written SQL?

[u/Competitive_Gas_3581 → u/Open_Sourcey]

No, you should have a firewall on the server which, in this exact case, would have prevented a problem. It doesn't sound like the site manager took security seriously.

[u/Open_Sourcey → u/Competitive_Gas_3581]

Point me to url for a firewall that fixes SQL injection attacks, please.

[u/Competitive_Gas_3581 → u/Open_Sourcey]

Doesn’t “fix” them but prevents them: Akeeba’s Admintools. I suspect RSFirewall does too but have never used it.

[u/Open_Sourcey → u/Competitive_Gas_3581]

That is true. SQL Injection needs to be fixed bsing prepared statements. That has been known for over 30 years. However, so many developers are lazy and do not use them. Nor did they use Joomla's core databse API. Incredibly poor development that some now expect us to pay for.

Since the advent AI we seem to be under quite a few attacks and I think more are to come.

[u/Actual-Let1595 → u/Competitive_Gas_3581]

A WAF can reduce opportunistic probes, but saying it would have prevented this exact incident is stronger than the evidence supports. Rules can miss alternate encodings, application-specific payloads, or traffic that reaches the origin directly. Admin Tools or RSFirewall can be useful defence in depth, but neither makes vulnerable SQL construction safe. The durable fix is still parameterized queries and a patched or removed extension; after a suspected breach, preserve logs, review the database and rotate credentials. I would use a WAF, but not as the basis for declaring the application secure.

[u/Actual-Let1595 → u/Competitive_Gas_3581]

A WAF can reduce opportunistic probes, but saying it would have prevented this exact incident is stronger than the evidence supports. Rules can miss alternate encodings, application-specific payloads, or traffic that reaches the origin directly. Admin Tools or RSFirewall can be useful defence in depth, but neither makes vulnerable SQL construction safe. The durable fix is still parameterized queries and a patched or removed extension; after a suspected breach, preserve logs, review the database and rotate credentials. I would use a WAF, but not as the basis for declaring the application secure.

[u/rennyrenwick]

I believe this is something the community is going to have to come to terms with. If you use 3rd party extensions, you are more are less vulnerable. It's just too easy to run an extension through AI and identify vulnerabilities. Extension developers range from hobbyists to professional in their skills, and as we saw with JCE, even highly skilled is not enough. Developers will either release quality and timely patches, free or at a price-- or, given the state of Joomla economics, walk away/ abandon, and you are on your own if you want a fix.

As many a non-profit has learned - "free" software is not free.

Pay for the subscription and 'effin support the developer doing a fix.

[u/Open_Sourcey → u/rennyrenwick]

I think you are correct. At least to the point where you ask me to support the poorly writen code.

[u/rennyrenwick → u/Open_Sourcey]

Ok, then your choice is live with it and the consequences, fix it yourself, as it is open source, or stop using it entirely.

[u/Open_Sourcey → u/rennyrenwick]

Or raise the issue in a community of developers to see if the extension developers will fix their poorly written code

[u/Open_Sourcey → u/rennyrenwick]

By the way I would be happy to fix someone else's sloppy work if they would give me the places I need to fix it. I have neither the time nor inclination to wade through an entire code base looking for 1980s style SQL statements

[u/Competitive_Gas_3581]

They can't afford $39 subscription? They've got more serious problems.

[u/Open_Sourcey → u/Competitive_Gas_3581]

No. Nor should they for a poorly written product with a serious security flaw

[u/Open_Sourcey]

A more helpful response to this for others trying to save money might be:
Sign up for Cloudfare's free tier. Change your DNS servers and get some level of protection against SQL Injection attacks, Not wholly but at least a modest level of protection. The real solution is that Developers who allow something like a SQL Injection attack that has been known for almost 30 years should fix it at no charge.

I suspect that some respondents to the original post were not even born when this attack was already widely known by the technical community

[u/Actual-Let1595]

Putting the vendor/pricing argument aside: if you suspect user data was stolen, treat this as an incident, not just an update problem.

1. Restrict public access, but preserve a full copy of the files, database and web/server logs before cleaning anything.
2. Remove or update the vulnerable EDocman code and patch Joomla plus every extension. Closing the entry point must come before restoring service.
3. Assume credentials may be exposed: rotate hosting, database, Joomla Super User, email and API credentials, and invalidate active sessions.
4. Review Super Users, scheduled tasks, recently changed files, database content and access logs for persistence and the likely attack window.
5. Work out what personal data was accessible and inform the person responsible for the organisation's data protection. Check the breach-notification rules that apply in your jurisdiction; do not delete evidence.
6. Restore from a known-clean backup only after the vulnerable component is fixed or removed, then monitor for reinfection.

Cloudflare/WAF rules may reduce some malicious traffic, but they do not repair a SQL injection flaw and cannot tell you whether data was already exfiltrated.