Skip to main content
Version: 6.2 (Upcoming)

Security

Secure Coding Guidelines​

For general information about security development of Joomla extensions, see the generic Security section.

Policies and Best Practices​

It's barely a question if your extension will ever have a security vulnerability, it's just a matter of when. So, establishing security best practices, policies and workflows is a vital part of developing Joomla extensions.

1. Establish a clear security reporting channel​

Every publicly available Joomla extension should provide an obvious way to report security vulnerabilities.

Recommended:

  • A dedicated security contact such as [email protected]
  • A SECURITY.md file in the source repository
  • A security page on the vendor website
  • Clear instructions on what information should be included
  • An explicit statement that security reports should not be submitted through public issue trackers

The reporting channel should ideally support encrypted communication for sensitive reports.

A security policy should state:

  • How reports are received
  • Expected response times
  • How vulnerabilities are handled
  • How disclosure is coordinated
  • Whether reporters are credited
  • Whether CVE IDs are assigned

This follows the general principles of ISO/IEC 29147, which covers receiving vulnerability reports and communicating remediation information.

2. Treat security reports confidentially​

A vulnerability report should initially be treated as confidential.

Do not:

  • Create a public GitHub issue
  • Publish the proof of concept
  • Discuss the vulnerability publicly
  • Include exploit details in public commit messages or changelogs

until a coordinated disclosure date has been agreed upon.

Internally, the report should receive a unique tracking ID and have a clearly defined owner.

A useful lifecycle is:

Reported
   ↓
Acknowledged
   ↓
Validated
   ↓
Severity assessed
   ↓
Fix developed
   ↓
Fix verified
   ↓
CVE assigned
   ↓
Coordinated disclosure
   ↓
Public advisory
   ↓
Post-disclosure monitoring

3. Acknowledge the reporter quickly​

A reporter should receive an acknowledgement even if the vulnerability has not yet been validated.

Recommended targets:

  • Within 1 business day: acknowledge receipt
  • Within 3–5 business days: provide an initial assessment
  • During longer investigations: provide regular status updates

The acknowledgement should explain:

  • That the report was received
  • Who is handling it
  • Whether additional information is required
  • What the next steps are

4. Validate the vulnerability​

The maintainer should establish:

  • Affected extension/component
  • Affected versions
  • Supported Joomla versions
  • Attack prerequisites
  • Required user privileges
  • Whether authentication is required
  • Whether user interaction is required
  • Actual security impact
  • Exploitability
  • Whether the issue has already been publicly disclosed
  • Whether another vendor or dependency is affected

The reporter should be given the opportunity to provide additional technical information or a proof of concept.

5. Distinguish security bugs from ordinary bugs​

Not every bug is a security vulnerability.

Examples of typical security vulnerabilities include:

  • SQL Injection
  • Cross-Site Scripting (XSS)
  • Cross-Site Request Forgery (CSRF)
  • Authentication bypass
  • Authorization/access-control bypass
  • Privilege escalation
  • Arbitrary file upload
  • Arbitrary file deletion
  • Path traversal
  • Remote or local code execution
  • Sensitive information disclosure
  • Insecure deserialization
  • Server-Side Request Forgery (SSRF)

A vulnerability should be assessed based on its security impact, not merely on how severe the underlying coding mistake appears.

6. Assess severity consistently​

Use a standardized scoring system rather than arbitrary labels such as "critical" or "minor".

CVSS 4.0 is the recommended standard for communicating vulnerability severity.

At minimum, record:

CVSS:4.0/...
Base Score: 8.3
Severity: High

Also document the practical prerequisites, for example:

Attack Vector: Network
Privileges Required: Low
User Interaction: Required
Affected functionality: Administrator
Exploitability: Requires authenticated Joomla user

Do not treat the CVSS Base Score as the complete risk assessment. Consider the actual deployment environment and current threat situation as well.

7. Develop the fix privately​

The fix should be developed without exposing the vulnerability.

Recommended practices:

  • Private branch
  • Private repository where necessary
  • Security-specific test cases
  • Regression tests
  • Review by at least one additional developer
  • Testing against all supported Joomla versions

The security fix should ideally include a regression test that:

  1. Fails against the vulnerable implementation
  2. Passes against the fixed implementation

8. Consider downstream dependencies​

A Joomla extension may itself contain or depend on other software.

Before disclosure, check whether the vulnerability also affects:

  • Joomla itself
  • Another Joomla extension
  • A third-party PHP library
  • JavaScript dependencies
  • An API or external service
  • Another vendor's product
  • Bundled or copied code

If multiple parties are affected, use Coordinated Vulnerability Disclosure (CVD) rather than disclosing independently.

9. Coordinate a disclosure date​

The goal should not be to keep a vulnerability secret indefinitely.

Instead, agree on a reasonable disclosure timeline.

A practical model:

Day 0       Report received
Day 1       Acknowledgement
Day 3–5     Initial assessment
             ↓
             Fix development
             ↓
             CVE coordination
             ↓
             Fixed version released
             ↓
             Public advisory

The exact timeline should depend on severity and exploitability.

For a vulnerability that is already being exploited in the wild, the process should be accelerated substantially.

For vulnerabilities affecting several vendors, the disclosure date should be coordinated between all relevant parties.

10. CVE IDs​

A CVE ID identifies a vulnerability, not a software release or a particular patch.

For example:

CVE-2026-12345

is associated with the vulnerability itself.

Do not create a separate CVE merely because different releases address the same vulnerability.

Separate vulnerabilities should normally receive separate CVE IDs.

Joomla extensions​

Joomla extension developers can request a CVE ID from the Joomla security team by contacting:

[email protected]

The CVE assignment should be coordinated with Joomla's CVE Numbering Authority (CNA) rather than inventing or requesting an arbitrary CVE number.

11. Assign the CVE before public disclosure​

Ideally, the first public security advisory should already contain the CVE ID.

Extension developers can request the CVE ID from:

[email protected]

before public disclosure so that it can be included in the initial announcement.

The CVE ID should be associated with the vulnerability and consistently referenced across:

  • Security advisory
  • Changelog
  • Release notes
  • CVE record
  • Joomla security communication
  • Other relevant security databases

Follow the current CVE Program and CNA publication requirements and coordinate embargoes where applicable.

12. Credit the security researcher​

Always offer appropriate credit to the reporter.

For example:

This vulnerability was responsibly reported by
Jane Doe (@janedoe).

We thank Jane for responsibly reporting this issue
and helping us improve the security of this extension.

However:

Never publish a reporter's name, handle, company or other identifying information without their consent.

Ask the reporter exactly how they want to be credited.

Possible choices include:

Name:
Jane Doe

Handle:
@janedoe

Organization:
Security Research Lab

Anonymous:
Yes

Confirm that the proposed credit is acceptable before publication.

13. Publish a security advisory​

Do not rely exclusively on a generic changelog such as:

1.4.2
- Various bug fixes and improvements

Publish a dedicated security advisory.

A proper advisory should contain:

Security Advisory

Product
Example Joomla Extension

Vulnerability
Stored Cross-Site Scripting

CVE
CVE-2026-12345

Affected Versions
1.0.0 – 1.4.1

Fixed Versions
1.4.2 and later

Severity
High

CVSS
CVSS:4.0/...

Impact
An authenticated user with ... can ...

Description
...

Solution
Update to version 1.4.2 or later.

Credits
Reported by Jane Doe.

Timeline
2026-07-01  Report received
2026-07-02  Vulnerability confirmed
2026-07-15  Fix released
2026-07-15  Advisory published

Joomla's own security advisories provide a useful model: they identify affected versions, impact, severity, exploit type, report/fix dates, CVE number, description, solution and reporter.

14. Tell users what they need to do​

The most important information for users is:

Am I affected, and what should I do?

Every advisory should clearly state:

Affected versions​

Versions 2.0.0 through 2.4.7 are affected.

Fixed versions​

Upgrade to 2.4.8 or later.
All users running an affected version should update immediately.

If updating is not possible, provide a mitigation where one genuinely exists.

For example:

Until the extension can be updated, disable the affected
administrator endpoint.

Do not recommend a mitigation that has not been tested.

15. Explain the vulnerability without unnecessarily publishing an exploit​

A security advisory should provide enough information for administrators to understand the risk.

It should answer:

  • What is the vulnerability?
  • Who can exploit it?
  • Is authentication required?
  • What can an attacker accomplish?
  • Which versions are affected?
  • Is exploitation known?
  • How can users fix it?

A vendor does not necessarily need to publish a working exploit/PoC immediately.

Especially for high-impact vulnerabilities, avoid publishing exploit details that materially increase the risk to users who have not yet updated.

The principle should be:

Transparency sufficient for risk assessment, without unnecessarily increasing exploitability.

16. Notify users through appropriate channels​

Security fixes should be communicated through channels users actually monitor.

Depending on the extension:

  • Extension update mechanism
  • Joomla Extension Directory
  • Vendor website
  • Security advisory page
  • Mailing list
  • RSS feed
  • GitHub Security Advisory
  • Newsletter
  • Social media, where appropriate

The Joomla Security Centre provides a public security announcement feed that users can subscribe to.

For particularly severe vulnerabilities, do not rely exclusively on a changelog.

17. Do not hide security fixes in vague language​

Avoid:

Various bug fixes and improvements

when a security vulnerability was fixed.

Prefer:

Security: Fixed an authenticated SQL injection vulnerability
in the administrator filtering functionality.

CVE-2026-12345

Security transparency helps users make informed decisions about updates.

18. Preserve the disclosure timeline​

Maintain an internal timeline for every security issue:

2026-07-01  Vulnerability reported
2026-07-01  Report acknowledged
2026-07-03  Vulnerability confirmed
2026-07-04  CVE requested
2026-07-08  Fix completed
2026-07-10  Fix provided to reporter for verification
2026-07-12  Fixed release published
2026-07-12  CVE published
2026-07-12  Security advisory published

This is useful for:

  • Internal audits
  • Communication with researchers
  • CVE records
  • Incident response
  • Process improvements

19. Handle reports that are already public​

Sometimes a researcher publishes a vulnerability before contacting the vendor.

Do not automatically treat this as malicious.

Instead:

  1. Acknowledge the report
  2. Assess the vulnerability
  3. Determine whether a CVE already exists
  4. Coordinate with the reporter where possible
  5. Release a fix as quickly as practical
  6. Publish an advisory

The CVE process also provides mechanisms for vulnerabilities that have already been publicly disclosed.

20. Do not retaliate against good-faith researchers​

A responsible disclosure process should explicitly state that good-faith security research is welcome.

A useful policy statement is:

We welcome good-faith security research and responsible vulnerability disclosure. Researchers who follow this policy will not be subject to legal action by us solely for activities conducted in accordance with this policy.

However, define reasonable boundaries around:

  • Accessing other users' data
  • Destructive testing
  • Denial-of-service testing
  • Social engineering
  • Automated scanning of third-party infrastructure
  • Persistence
  • Data exfiltration