[BUG]: Component not passing tests in JED Checker

2026-03-03 18:31:48 +00:00

What Happened?

I checked my compiled component and there are some basic checks which don't pass a JED Checker scan. Some in particular:

The XML manifest references folders which don't exist:
Folder not found: admin/presets
Folder not found: admin/services
Folder not found: admin/sql/updates/mysql/

"PHP Files missing JEXEC security"
Some files have the \defined('_JEXEC') or die; statement but it is after other header lines so the test fails. For example:
/site/tmpl/myview/edit.php
/site/src/Helper/MyComponentHelper.php

It also warns about "Base64 or other type of encoding in the files".
And also: "JAMSS - Joomla! Anti-Malware Scan Script" Pattern found#17 - PHP: multiple encoded, most probably obfuscated code found

Steps to reproduce the Bug

Compile component, install JED Checker component, upload JCB component to JED Checker.

Which Joomla version are you compiling in?

6.0.3

Which PHP version are you compiling in?

8.3.27

Which Joomla versions are you targeting?

6.0.0

Which PHP version are you targeting?

8.3.27

Which Web server is JCB running on?

Joomla Docker image "joomla:5.4.0-php8.3". Apache 2

Which Relational Database is JCB running on?

mysqlnd 8.3.27

Which OS is JCB running on?

Alpine linux

Which JCB version are you using?

6.1.4

Where in JCB did this issue occur?

Compilation of a component

On which browsers did you encounter the issue?

Firefox, Chrome

Additional Comments

Perhaps this component will simply require review by a human instead of the Joomla automated system, but it would be nice to avoid that if possible.

### What Happened? I checked my compiled component and there are some basic checks which don't pass a JED Checker scan. Some in particular: The XML manifest references folders which don't exist: Folder not found: admin/presets Folder not found: admin/services Folder not found: admin/sql/updates/mysql/ "PHP Files missing JEXEC security" Some files have the \defined('_JEXEC') or die; statement but it is after other header lines so the test fails. For example: /site/tmpl/myview/edit.php /site/src/Helper/MyComponentHelper.php It also warns about "Base64 or other type of encoding in the files". And also: "JAMSS - Joomla! Anti-Malware Scan Script" Pattern found#17 - PHP: multiple encoded, most probably obfuscated code found ### Steps to reproduce the Bug Compile component, install JED Checker component, upload JCB component to JED Checker. ### Which Joomla version are you compiling in? 6.0.3 ### Which PHP version are you compiling in? 8.3.27 ### Which Joomla versions are you targeting? 6.0.0 ### Which PHP version are you targeting? 8.3.27 ### Which Web server is JCB running on? Joomla Docker image "joomla:5.4.0-php8.3". Apache 2 ### Which Relational Database is JCB running on? mysqlnd 8.3.27 ### Which OS is JCB running on? Alpine linux ### Which JCB version are you using? 6.1.4 ### Where in JCB did this issue occur? Compilation of a component ### On which browsers did you encounter the issue? Firefox, Chrome ### Additional Comments Perhaps this component will simply require review by a human instead of the Joomla automated system, but it would be nice to avoid that if possible.

ConfidantCommunications added the Bug label 2026-03-03 18:31:49 +00:00

Lemuel commented

2026-03-10 12:13:57 +00:00

Owner

Thanks for taking the time to run the component through the JED Checker and for reporting the results. Let me clarify the points you mentioned and also provide some broader context about how the checker behaves with components generated by Joomla Component Builder (JCB).

Missing folders in the XML manifest

Joomla Component Builder defines several folders in the manifest that are part of the standard component structure, such as:

admin/presets
admin/services
admin/sql/updates/mysql

If you look at the JCB source repository itself, you will see that these folders exist. However, some of them are only created when they are actually needed.

For example, the admin/sql/updates/mysql directory is generated once the component starts producing update scripts (which happens when structural changes require database migrations). If a component has not yet produced updates, the folder will not exist.

The same logic applies to other optional directories. The manifest reflects the full component architecture, but not every project will contain every directory from the beginning.

JEXEC security warning

Regarding the warning about missing defined('_JEXEC') checks:

The helper class and other files do include the standard Joomla security guard:

\defined('_JEXEC') or die;

In some cases this statement may appear after a small amount of initialization logic. This is intentional.

JCB sometimes loads its internal autoloader first so that classes originating from the Power area can be resolved correctly. Because of that requirement, a small bootstrap section may appear before the JEXEC guard. Some scanners expect the guard to be the first executable line in the file and therefore incorrectly report it as missing.

Additionally, template files and certain library-style classes are structured differently from entry-point scripts, which can also lead automated scanners to flag them incorrectly.

Base64 encoding warning

The Base64 warning usually relates to Joomla's standard redirect pattern.

Joomla commonly encodes return URLs using Base64 so that they can safely be passed as parameters such as:

return=BASE64_STRING

When the request completes, Joomla decodes the value, validates that it points to an internal URL, and redirects the user back to that page. This behavior is widely used in Joomla core and is not obfuscation.

Because the checker only detects encoded strings, it can sometimes flag legitimate Joomla usage as suspicious.

JAMSS encoded pattern warning

The same applies to the JAMSS rule that flags encoded strings. Automated scanners cannot always distinguish between legitimate encoding and malicious obfuscation. In this case the encoding originates from standard Joomla functionality rather than hidden or obfuscated code.

Important context when using the JED Checker

When running a Joomla component through the JED Checker, there are a few important points to keep in mind:

1. False positives can occur
The JED Checker sometimes reports issues that are not actually present. For example, it may report that a PHP file is missing the JEXEC security check even though the check is clearly present in the file.

2. Some issues can be addressed in the component setup
Certain warnings or notices reported by the checker can be resolved by adjusting how the component is configured or built within JCB.

3. The JED Checker is not a complete source of truth
While the tool is useful as a guideline, it is not fully fail-safe and should not be treated as the sole authority on code quality or compliance.

4. Third-party libraries may trigger warnings
Libraries such as phpspreadsheet may produce warnings (for example, about missing GPL licenses). These are external dependencies that we do not maintain, and such warnings do not necessarily indicate a problem with the component itself.

5. Ongoing work on deprecations and modernization
We are actively identifying and resolving deprecated or outdated code within the JCB compiler. This is a substantial effort considering JCB currently consists of more than 1.3 million lines of code. (keep in mind we still have support for J3 and J4)

JCB itself is built using the same architecture it generates for other components. If you inspect the JCB repository you will see the same patterns used there as well.

If you believe the JED Checker could better account for these Joomla conventions, contributions or improvements to the checker project would certainly help reduce these kinds of false positives.

I hope this clarifies the situation. Let me know if you need further details.

Thanks for taking the time to run the component through the JED Checker and for reporting the results. Let me clarify the points you mentioned and also provide some broader context about how the checker behaves with components generated by Joomla Component Builder (JCB). ### Missing folders in the XML manifest Joomla Component Builder defines several folders in the manifest that are part of the standard component structure, such as: * `admin/presets` * `admin/services` * `admin/sql/updates/mysql` If you look at the JCB source repository itself, you will see that these folders exist. However, some of them are only created when they are actually needed. For example, the `admin/sql/updates/mysql` directory is generated once the component starts producing update scripts (which happens when structural changes require database migrations). If a component has not yet produced updates, the folder will not exist. The same logic applies to other optional directories. The manifest reflects the full component architecture, but not every project will contain every directory from the beginning. ### JEXEC security warning Regarding the warning about missing `defined('_JEXEC')` checks: The helper class and other files do include the standard Joomla security guard: ``` \defined('_JEXEC') or die; ``` In some cases this statement may appear after a small amount of initialization logic. This is intentional. JCB sometimes loads its internal autoloader first so that classes originating from the **Power area** can be resolved correctly. Because of that requirement, a small bootstrap section may appear before the JEXEC guard. Some scanners expect the guard to be the first executable line in the file and therefore incorrectly report it as missing. Additionally, template files and certain library-style classes are structured differently from entry-point scripts, which can also lead automated scanners to flag them incorrectly. ### Base64 encoding warning The Base64 warning usually relates to Joomla's standard redirect pattern. Joomla commonly encodes return URLs using Base64 so that they can safely be passed as parameters such as: ```return=BASE64_STRING``` When the request completes, Joomla decodes the value, validates that it points to an internal URL, and redirects the user back to that page. This behavior is widely used in Joomla core and is not obfuscation. Because the checker only detects encoded strings, it can sometimes flag legitimate Joomla usage as suspicious. ### JAMSS encoded pattern warning The same applies to the JAMSS rule that flags encoded strings. Automated scanners cannot always distinguish between legitimate encoding and malicious obfuscation. In this case the encoding originates from standard Joomla functionality rather than hidden or obfuscated code. --- ### Important context when using the JED Checker When running a Joomla component through the JED Checker, there are a few important points to keep in mind: **1. False positives can occur** The JED Checker sometimes reports issues that are not actually present. For example, it may report that a PHP file is missing the `JEXEC` security check even though the check is clearly present in the file. **2. Some issues can be addressed in the component setup** Certain warnings or notices reported by the checker can be resolved by adjusting how the component is configured or built within JCB. **3. The JED Checker is not a complete source of truth** While the tool is useful as a guideline, it is not fully fail-safe and should not be treated as the sole authority on code quality or compliance. **4. Third-party libraries may trigger warnings** Libraries such as **phpspreadsheet** may produce warnings (for example, about missing GPL licenses). These are external dependencies that we do not maintain, and such warnings do not necessarily indicate a problem with the component itself. **5. Ongoing work on deprecations and modernization** We are actively identifying and resolving deprecated or outdated code within the JCB compiler. This is a substantial effort considering JCB currently consists of more than **1.3 million lines of code**. (keep in mind we still have support for J3 and J4) JCB itself is built using the same architecture it generates for other components. If you inspect the JCB repository you will see the same patterns used there as well. If you believe the JED Checker could better account for these Joomla conventions, contributions or improvements to the checker project would certainly help reduce these kinds of false positives. I hope this clarifies the situation. Let me know if you need further details.

Lemuel added question and removed Bug labels 2026-03-10 12:24:11 +00:00

ConfidantCommunications commented

2026-03-10 20:10:57 +00:00

Author

Thank you very much for the detailed explanations Lemuel. Take care and God bless you.

ConfidantCommunications closed this issue

2026-03-10 20:10:59 +00:00

[BUG]: Component not passing tests in JED Checker #1288