Polnisch 
English Kowal Security Scan is an advanced security module for Magento 2 that helps detect suspicious file changes, malicious code, dangerous URLs, and injections in database content faster. It was designed to run lightly, without additional agents and without complex deployment.
WhatsApp
+48608012047php, phtml, js, html, svg, htaccess files and other payload carriers.decode -> execute chains, dynamic callbacks, variable function calls, and suspicious include/require usage.data: URI, and dangerous links.rule_id, so allowlist configuration does not depend on the full text description.e-val, base-64_decode, gzin-flate, and similar techniques,data: URI,The module analyzes key store areas where incidents most commonly appear:
core_config_data,rule_id.rule_id help maintain high effectiveness without a flood of false alarms.Deployment and configuration documentation is available for the module, and its architecture supports further tuning of rules and security processes in a Magento 2 store.
Improve early incident detection in Magento 2 with Kowal Security Scan.
We expanded the Kowal_SecurityScan module with new features related to threat analysis and report administration.
Kowal_SecurityScanThe module extends Magento 2 with a security monitoring layer for application files, selected database tables, suspicious URLs, and optional incident analysis by OpenAI.
Reports are stored in the kowal_securityscan_report table and can be sent by email.
php, phtml, php5, inc, phar,
js, html, htm, svg, htaccess files,
token_get_all(),data: URI, and suspicious
URLs,
kowal/base module,If the package is not available in the default Composer repository, add the source:
composer config repositories.securityscan vcs https://github.com/kowalco/module-securityscanIf the repository requires authorization:
composer config --global --auth github-oauth.github.com composer require kowal/module-securityscanphp bin/magento module:enable Kowal_SecurityScanphp bin/magento setup:upgradephp bin/magento cache:flushIn a production environment, perform the standard Magento deployment steps according to your deployment process.
The module registers its own cron group securityscan.
kowal_securityscan_filecheck - daily at 00:00,kowal_securityscan_malwarecheck - daily at 01:00,kowal_securityscan_dbcheck - daily at 02:00,kowal_securityscan_cleanup_reports - daily at 02:30.Without a working Magento cron, automatic scans will not run.
To run scans manually, use:
php bin/magento kowal_securityscan:filecheckphp bin/magento kowal_securityscan:malwarecheckphp bin/magento kowal_securityscan:dbcheckThis is the recommended testing method after installation and after configuration changes.
Configuration path:
Stores -> Configuration -> kowal -> kowal_security
Enable moduleReport recipient email addressSender email addressReport retention in daysGoogle Safe Browsing API KeyDomain allowlistFile allowlistDatabase pattern allowlistFile rule allowlistDatabase rule allowlistThe OpenAI Analysis section lets you extend reports with risk assessment and recommended actions.
Available fields:
Enable AI analysis,OpenAI API Key,OpenAI Model,Maximum context for AI.Enable AI analysis,OpenAI API Key,gpt-4.1-mini,12000,2000 are raised to 12000,50000.If OpenAI is disabled or the key is missing, the module still works and uses local heuristics.
If you fill in the Google Safe Browsing API Key, the module will:
Missing a key does not block basic scans, it only disables this stage.
filecheck works based on a snapshot saved to:
var/security_scan_hashes.json
On the first run:
Subsequent runs report changes of type ADDED, MODIFIED, and REMOVED.
The following are skipped, among others:
var/,generated/,vendor/,pub/static/,node_modules/.malwarecheck scans application files based on:
rule_id,Example detection types:
file.obfuscated_eval_chain,file.command_execution_from_request,file.encoded_payload_blob,file.token.decode_execute_chain,file.token.include_from_request,file.inline_svg_or_event_handler.In reports, reasons are presented in the format:
[file.encoded_payload_blob] Encoded payload blob detecteddbcheck analyzes selected Magento tables:
cms_block,cms_page,core_config_data,email_template,newsletter_template,review_detail,catalog_product_entity_text.Example rules:
db.inline_script_tag,db.html_event_handler,db.external_iframe,db.javascript_uri,db.data_uri_executable,db.embedded_svg_payload,db.javascript_dom_redirect.Content is normalized beforehand using:
html_entity_decode,rawurldecode,Allowlists are used to reduce false positives without disabling the entire module.
Field: kowal_security/general/allowlisted_domains
Format:
cdn.example.comstatic.example.orgEffect:
Field: kowal_security/general/allowlisted_file_patterns
Format:
app/code/Vendor/Module/Test/*pub/media/custom.jsEffect: files matching the pattern are completely skipped by the malware scan. This setting has a broad scope.
Field: kowal_security/general/allowlisted_db_patterns
Format:
trusted-inline-widgetdata:image/svg+xmlEffect: a database record containing such a fragment is skipped by the DB scan. This setting also has a broad
scope.
4. File rule allowlist
Field: kowal_security/general/allowlisted_file_rules
Preferred format:
path_or_glob | rule_id
Example:
app/code/Vendor/Module/* | file.encoded_payload_blobpub/media/custom.js | file.javascript_redirect_or_rewrite
Backward compatibility:
- old entries by full rule label still work,
- new entries should use
rule_id.
Effect: only the specified rule is silenced for the specified path, while the rest of the scan for that file
still works.
5. Database rule allowlist
Field: kowal_security/general/allowlisted_db_rules
Preferred format:
table_or_* | rule_id
Example:
cms_block | db.inline_script_tag* | db.fetch_or_xhr_loader
Effect: only the specified rule is silenced, while the others still work for that record or table.
Reports
Reports may contain:
- a list of detections,
- risk assessment,
- indicators and recommendations,
- allowlist candidates after manual verification,
- normalized allowlist configuration in JSON.
Allowlist suggestions in reports
The report section may contain entries such as:
- cms_block | db.inline_script_tag | confidence=MEDIUM | scope=LOW- app/code/Vendor/Module/* | file.encoded_payload_blob | confidence=MEDIUM | scope=LOW- data:image/svg+xml,
Interpretation:
scope=LOW - safer candidate,scope=HIGH - broad silencing, only after strict verification,confidence=MEDIUM/HIGH - more predictable configuration candidate,confidence=LOW - requires caution.
JSON export
The report also contains the Normalized allowlist configuration (JSON) section. This is a ready,
deduplicated set of values to copy into the configuration.
Recommended usage flow
- run all three scans manually after installation,
- treat the first
filecheck as snapshot creation,
- analyze reports and confirm which detections are real,
- for false positives, first use
allowlisted_file_rules and allowlisted_db_rules,
- only when necessary, use
allowlisted_domains, allowlisted_file_patterns, and
allowlisted_db_patterns,
- after changing configuration, rerun the appropriate CLI scan and check the result.
Operational notes
filecheck does not yet report changes as an incident on the first run,- the module works without OpenAI and without Safe Browsing, but with lower analysis depth,
allowlisted_file_patterns and allowlisted_db_patterns have broad impact and
should be used sparingly,
- the preferred format for rule allowlists is
rule_id, not the full text label.
