How to Find and Fix the JCE Profiles Hack Using mySites.guru (June 2026)

Quick summary: what this guide covers

A recent pattern of compromises has used JCE editor profiles (editor configuration/data) as a persistence or backdoor vector. Tools such as mySites.guru have added dedicated checks to detect indicators of these incidents. This guide shows a safe workflow for using those checks, how to prepare backups and evidence, and manual alternatives if you cannot use the service.

At‑a‑glance workflow

• Take a mySites.guru snapshot (or similar site snapshot).
• Create a full site backup (Akeeba Backup recommended) and store it offsite.
• Export any flagged profiles/files as evidence.
• Run remediation via mySites.guru or follow the manual cleanup steps.
• Verify the site, update JCE/Joomla/extensions, rotate credentials, and monitor.

Who this is for

This guide is written for Joomla site owners, administrators and beginners who maintain sites. If you see signs of a deep compromise (persistent reinfection, unknown outbound connections, or evidence of data access), consider engaging an incident response professional.

Immediate checklist (one line)

Snapshot → full backup (Akeeba) → export flagged items → remediation → verify front‑end/admin → update & rotate passwords.

Understanding the issue: JCE editor profiles and why rogue profiles matter

JCE editor profiles are configuration entries and related files used to control editor behavior. Attackers can abuse these structures to hide code, cause file writes, or trigger actions that act as backdoors. A compromised profile can be a stealthy persistence mechanism, and it is often found alongside explicit webshell files placed in the filesystem.

High‑level anatomy of this kind of compromise (editor profiles vs. webshells)

• Editor profiles — typically stored in extension configuration or database records; may contain serialized or encoded data. Malicious payloads can be hidden inside profile content or referenced files.
• Webshells — files uploaded to the webroot or upload directories that allow remote command execution or file manipulation. They are explicit backdoors and often co‑exist with modified profiles.

How attackers use rogue profiles (plain language)

Attackers may add or modify editor profiles to store code or to create features that cause the site to save files, execute commands, or add admin accounts. Techniques vary, and attackers often obfuscate payloads. This guide focuses on detecting likely indicators and removing them safely.

Signs your site could be affected

• New or unexpected editor profiles visible in the CMS administrative UI.
• Unfamiliar PHP files in image/media/upload directories.
• New admin users or users with unusual privileges.
• Suspicious outbound connections from the server or unusual log entries.

Example scenario: after an automatic extension update you notice a JCE profile with a strange name and exported profile content that includes obfuscated code — treat this as suspicious and follow the safe workflow above.

About the mySites.guru detection + fix: what it checks and how it behaves

mySites.guru has added dedicated security checks that look for indicators related to rogue JCE profiles and potential dropped backdoors. The service typically reports flagged profile names, files on disk that look suspicious, and provides an option to export evidence for review. The design philosophy is safety-first: generate a snapshot and let the operator review and trigger remediation rather than deleting automatically.

What mySites.guru’s check typically reports

• List of flagged editor profiles with timestamps and brief context.
• Paths to suspicious files and snippets of file content for quick review.
• Export options for evidence (downloadable ZIP) and remediation actions the operator can trigger.

How often the check runs and where it appears

Checks may run on a schedule tied to snapshots or can be initiated from the mySites.guru dashboard. The exact cadence and UI flow should be confirmed in the mySites.guru documentation before relying on it operationally.

Why mySites.guru prefers review before deletion

Automated deletions risk removing files or data that are actually in use or custom to a site. Exporting evidence before remediation preserves forensic information and gives you the opportunity to validate the changes. Consider remediation via the tool as a targeted removal of known indicators, not a replacement for a full incident response when required.

Step‑by‑step: using mySites.guru to find and fix affected sites (safe workflow)

The following annotated workflow is designed to minimise risk while using a detection and remediation service. Verify any UI wording against the live mySites.guru interface before you act.

Preparing: snapshot, export evidence and full backup

1. Log into mySites.guru and create a fresh snapshot for the site — this preserves current state for investigation.
2. Create a full backup of the site (Akeeba Backup or equivalent). Download and store the backup outside the production server.
3. Open the security check for JCE/profile indicators and click the option to export flagged items. Save the ZIP in a secure offline location.
4. Label your backups and evidence clearly (site‑name_date_time) and store access credentials for the backup separately and securely.

Executing the one‑click fix from mySites.guru (what will happen)

Once you have a snapshot and backups:

• Trigger remediation in the mySites.guru UI. The tool should prompt for confirmation and report the snapshot used in case rollback is needed.
• Expect progress indicators and a remediation log. Download the log and keep it with your evidence set.
• If the remediation reports errors, stop and export logs; do not attempt unplanned manual deletions without consulting backups or a professional.

Verifying cleanup: file and admin checks, front‑end smoke tests

• Verify flagged files are removed or moved to a quarantine location. Compare file lists with the exported evidence ZIP.
• Log into the Joomla administrator and check for unknown users; disable or remove unauthorized accounts after taking backups.
• Perform a front‑end smoke test: navigate major pages, check forms, and ensure no immediate errors.
• Schedule an immediate re‑scan in mySites.guru and run any additional server‑side malware scanners you have available.

Manual detection and cleanup if you don't use mySites.guru

If mySites.guru is not available to you, a conservative manual approach is possible but riskier. Always start with a full backup and evidence export.

Manual file search: common directories and suspicious indicators

• Check upload and media directories (images, media, tmp) for unexpected PHP files — uploads directories normally should not contain executable PHP.
• Look for suspicious patterns: long random filenames, recently changed timestamps, obfuscated PHP (base64_decode, eval, gzinflate, extensive strings).
• Use trusted server file listing tools or your hosting control panel; prefer read‑only inspection until a backup exists.

Database checks: where to look for editor profile entries

Editor profiles are often stored as extension configuration or in database tables related to the editor. Because Joomla versions and extensions differ, do not run SQL statements without confirming exact table and column names for your installation. Instead:

1. Export a copy of the database (offline).
2. Search the exported SQL or CSV for likely profile names, suspicious serialized content, or PHP tags.
3. Keep exported rows as evidence rather than deleting database entries immediately.

Safe manual removal steps and rollback strategy

• If you must remove files manually, move them into a quarantine folder outside the webroot and keep them in the backup until the site is verified clean.
• Document every manual step and keep local copies of deleted files for future forensics.
• Prefer restoring to a known‑clean backup in staging for deep compromises rather than attempting piecemeal manual cleanup on production.

Aftercare: updates, passwords, scans and testing

After remediation, follow a disciplined post‑incident routine to reduce the risk of reinfection and to restore trust in the site.

Patching and updating

• Update JCE to the official patched release and update Joomla core and other extensions to supported versions.
• If your site uses many extensions or custom code, test updates in staging first to avoid compatibility problems.

Credentials and access controls

• Rotate all administrator, FTP/SFTP, database and API passwords after verifying cleanup.
• Enable two‑factor authentication for administrator accounts where available and remove unused admin users.

Re‑scanning schedule and monitoring

• Run an immediate re‑scan after remediation, then re‑scan at 24 hours, 7 days and monthly for a period.
• Set up file integrity monitoring, server logs review and alerting for unusual changes.

Backups and incident response: how to prepare and restore if needed

Reliable backups and a clear restore strategy are essential. A restore from a pre‑compromise backup is often the safest way to recover, but it requires careful validation.

Creating reliable backups (Akeeba guidance)

• Create a full site backup including files and database. Follow Akeeba's documentation for recommended settings and retention policies.
• Store backups offsite and verify that backups can be restored by periodically testing restores in a staging environment.

Restore vs cleanup: decision checklist

Consider a full restore when:

• Multiple unknown backdoors are present.
• Attacker persistence cannot be removed reliably.
• Data exfiltration or complex indicators suggest widespread compromise.

Working with incident responders

If you hire a professional, provide them with backups, exported evidence, remediation logs and timestamps of suspicious activity to speed up analysis.

Prevention: hardening tips and monitoring

After resolving an incident, reduce future risk by adopting practical hardening and monitoring measures.

Practical hardening steps

• Keep Joomla core, JCE and all extensions up to date and subscribe to security advisories for critical extensions.
• Remove unused extensions; prefer maintained and trusted projects.
• Harden filesystem permissions and use .htaccess or web server rules to block PHP execution in upload directories (test in staging first).
• Limit administrative access by IP where practical and enable two‑factor authentication.

Monitoring and notification

• Use automated scans, file integrity monitoring and set alerting for critical changes.
• Keep and regularly review security logs and configure notifications for suspicious activity.

Maintenance routine

• Monthly checks for updates, quarterly backup verification and scheduled security scans.

Where to get help and authoritative resources

Use official documentation and trusted providers when possible. Keep private credentials out of public support requests.

Official documentation to consult

• mySites.guru help and blog pages (verify the new check details in their documentation).
• JCE release notes or developer advisories for confirmed patched versions.
• Joomla security pages for guidance on best practices and supported versions.
• Akeeba Backup documentation for backup and restore procedures.

When to call in professionals

• Signs you need an incident responder: persistent reinfection, unknown outbound connections, evidence of data theft, or if you lack the skills/time to investigate safely.
• Provide responders with backups, exported evidence bundles, remediation logs and relevant timestamps to speed triage.

FAQ

What exactly is the 'JCE profiles hack' in simple terms?

Attackers create or modify JCE editor profiles or related files to hide malicious code or enable backdoors. The exact storage locations and methods vary; confirm database and extension details for your Joomla version before taking direct SQL actions.

Can mySites.guru automatically fix everything safely?

mySites.guru’s dedicated checks can detect and remediate known indicators, but you must snapshot and back up first. The remediation reduces risk but may not replace a full incident response for deeply compromised sites. Verify the tool’s exact behavior and supported Joomla versions in official mySites.guru documentation.

I don't use mySites.guru — can I do this manually?

Yes. The article includes manual detection steps, but manual actions carry greater risk. Always make multiple backups, export evidence, and quarantine suspicious files rather than deleting immediately. Verify any database or shell commands before running them.

How do I know the site is fully clean after remediation?

Re‑scan with multiple tools, verify flagged files are removed, review logs for suspicious activity, rotate credentials, monitor for recurrence, and consider professional help if reinfection occurs.

Which JCE version fixed the vulnerability?

The exact patched JCE version(s) must be confirmed from the official JCE changelog or advisory before publishing or acting. Do not assume a version without verification.

Should I restore from backup or clean in place?

Restoring from a pre‑compromise backup is often safest when multiple backdoors exist or persistence cannot be fully removed. If restoring, validate the backup in staging before returning it to production. Use the decision checklist earlier in this guide to choose.

When should I hire a professional?

Hire a professional for persistent reinfection, complex evidence of data exfiltration, or when you are uncomfortable performing the cleanup. Provide backups and exported evidence to speed the investigation.

Conclusion

Responding to a JCE profiles compromise requires a calm, systematic approach: snapshot, backup, export evidence, remediate and verify, then update and harden. Tools such as mySites.guru can streamline detection and provide a controlled remediation path, but always preserve evidence and test restores in staging. If you are unsure at any point, obtain professional assistance — careful handling preserves evidence and reduces the risk of accidental damage.

Verify the specific tool behaviors, patched JCE versions, and any database table names against official documentation before making production changes.