Remove remote SQL access from an old WordPress installation

Define the remote connection to close

After a migration, the server that hosted WordPress may remain authorized to reach the SQL database. A maintenance workstation or old export task may also appear in the allowed-host list. Before removing an entry, identify its actual use. The public site may have moved servers while billing processing remains hosted elsewhere. Removal must target an unnecessary connection origin, with evidence that consumers to retain have their own access.

Record the hosting account, relevant database, database server, and service requesting the change. An address in the access list is not necessarily the SQL server’s address. It may identify a client’s authorized origin. Ask the provider how this origin is represented when a relay or address translation is involved. A server may use an egress address different from the one displayed in its panel.

Confirm urgency. For routine migration completion, observing tasks helps prepare removal. If the old server was compromised, have the incident owner decide timing. Retaining access and maintaining task continuity must then be explicitly weighed.

Inventory database consumers

Consult WordPress configuration through the authorized channel to identify the database and SQL server. Record useful references without copying the password. Then request the list of standalone services connecting to this database. A remote backup, reporting tool, and import may have their own parameters. The WordPress file does not describe their access. For each, record owner, expected network origin, and execution frequency.

Also check other sites in the same hosting account. cPanel’s remote-host list may cover several account databases. An entry removed for an old site may still serve another. Confirm scope with the provider before deciding. Look for old copies retaining the same SQL username and note whether they are still authorized to read current data.

Build a matrix with one consumer per row. Associate service name, database, SQL account, origin, and latest connection evidence. An unknown address still needs attribution. Inactivity during a short window may correspond to a weekly task or manual intervention. Ask its owner to confirm removal.

Read the host list and identify overlapping rules

In cPanel, open Databases, then Remote Database Access. Older versions may display Remote MySQL. Record the exact entry and comment, along with other rules that may cover the same origin. Documentation accepts hostnames, IPv4, or IPv6 and describes using the percent character as a pattern. A precise entry may therefore overlap a broader pattern. Removing it alone may leave the same origin allowed.

Ask the provider what additional server-level rules exist. It may add hosts you do not manage directly. If a deleted entry reappears, have its management source examined before repeating. A hosting policy or automation may recreate it. The panel is not always a complete inventory of network and SQL controls.

For a hostname-based entry, confirm resolution and the server’s checking method. Do not infer behavior solely from your computer’s resolution. Also record any firewall rules and known indirect access. Removing access in cPanel addresses a defined scope and must be checked through a fresh connection.

Prepare rollback without changing credentials

Keep the entry list, comments, and approved scope in the private record. You must be able to restore a precise rule if a legitimate consumer was overlooked. Identify the person with cPanel access and the person able to handle a server rule. Check that their access works independently of the WordPress installation being checked. Avoid relying on a maintenance plugin that itself depends on the database.

Schedule the change when critical tasks are known. If a backup or write process still uses the origin, wait for completion or apply its authorized suspension mechanism. Removing permission does not establish that an already open connection immediately ends. Ask the operator how existing sessions are handled. A security emergency may require separate action on those sessions.

Database backup follows site policy, but initial rollback here concerns connection authorization. Restoring an old database may erase writes without restoring an access rule. Prepare configuration references and rollback authorization at the exact level where the change will be applied.

Remove the attributed entry in cPanel

In Manage Access Hosts, locate the validated entry’s name or address. Reread its comment and full value, then use Delete. The documented confirmation offers Remove Access Host. Check the result in the list. If the provider manages rules, request this same action with the exact value and scope, then retain its confirmation time. Do not remove unfamiliar entries in bulk.

If a broad rule covers several consumers, prepare narrowing to still-needed origins with the owner. First verify that required precise rules work. Change order matters when the general rule was the only thing permitting access. Ask provider support if the list cannot express the intended policy or covers a broader architecture than your site.

Removing a host and rotating the SQL password are independent decisions. If you must also retire a shared secret, prepare replacement with affected consumers. In this guide, retain credentials during the origin change so the result can be attributed to the removed rule.

For reproducible verification, separately record the origin observed by the SQL server, SQL account, and targeted database without the password. Keep the removed rule’s exact pattern. Two different site names may use the same egress address; retained-site success and old-consumer refusal must therefore be attributed to their respective connections.

Open a fresh connection from the site to retain

From the current WordPress installation’s authorized terminal, the following command opens a connection using its configuration and requests a constant value. Replace the root with the confirmed one. Expected output contains 1, with a zero exit code. It demonstrates an SQL connection from this context and execution of this query. Write permissions and web PHP operation require their own checks. A terminal may use configuration different from the page server’s.

Therefore also open an authorized dynamic route, such as a control draft in administration. A cached public page may continue displaying without a new SQL connection. If several frontends have distinct origins, request a check on each. Success from one server does not validate the entire group. For separate processes, record evidence of the next normal run with their owners.

Record the new connection’s time and context. If a process already had a session open before removal, do not use it as the sole proof that the new-connection rule is correct. Request a targeted observation revealing neither business queries nor secrets.

wp --path=/chemin/vers/wordpress db query 'SELECT 1;' --skip-column-names --batch

Verify refusal of the removed origin

If you still control the old server and the plan authorizes a negative check, use its approved client to open a new connection to the same database with already known parameters. The expected result is refusal of the targeted access. Have source context and destination confirmed. Failure caused by a wrong server name or replaced secret does not demonstrate an effective host rule. Avoid entering a secret in a command retained in shared history.

If the team can no longer access the old server, ask the provider to confirm removal and any rules that might still cover its origin. Describe the available evidence as configuration confirmation. An actually observed network or SQL refusal remains a separate evidence category. Do not restart the old server solely to obtain a test if its shutdown forms part of migration.

For a broad pattern, check other known authorizations before declaring the origin excluded. A VPN path, bastion, or shared egress may still provide another authorized origin. The conclusion must remain tied to the route examined.

Diagnose a failing legitimate service

If current WordPress loses access immediately after removal, compare that service’s actual origin with the matrix. A frontend may use the same egress address as the old server or a shared relay. Restore the approved rule if the rollback plan allows, then request more precise attribution. Avoid adding a pattern allowing every origin to accelerate recovery.

If only an export or overnight process fails, identify its database and SQL account. Check whether it shares the hosting account or depends on a server rule. Record error and time without disclosing the secret. Authentication refusal, no network route, and an unknown database may have different causes. Context lets the provider check the correct level.

When a removed rule reappears, keep before-and-after records and ask who produces it. Repeated manual correction may create alternation that is hard to diagnose. Have the owning source corrected or the reason for the entry documented before another removal attempt.

Observe less frequent runs

Keep monitoring open until consumers whose schedules were included in the plan have run. For a weekly task, a check a few minutes after the change does not cover its use. Its owner can confirm a new origin or provide evidence of permanent shutdown. Record the age and nature of the latest observation instead of a general status such as everything works.

For a reporting tool, verify that it reads recent data from the expected database. A result still in its cache may hide an access failure. For a backup, check the newly produced file and connection log, then apply the usual restorability check. An old file in storage does not prove that the next run succeeded.

If you discover an overlooked consumer, attribute it before permanently restoring access. Moving it to a maintained origin or providing distinct access may be preferable. Document the owner’s decision and the temporary exception’s removal date, with a way to verify usage.

Examine an egress address shared by two applications

Suppose the old WordPress installation and an accounting tool used the same server for years. The site moved, but the tool must continue consulting the database from that server. Removing the entire address would interrupt both uses. Ask whether old WordPress has a dedicated SQL account and whether its secrets can be removed or replaced without affecting the tool. Scope reduction may then concern the account or architecture, with separate checks for each consumer.

In another case, two current frontends use a shared gateway. The panel may show only one origin for the group. Preserve the rule needed by the group and have the network owner confirm how the old server is separated from that gateway. An outdated cPanel label may justify updating the comment instead of deleting the entry. Record the service actually covered and evidence allowing this mapping to be found during the next review.

Close out the rule with its scope and owner

The final record must identify the removed entry, hosting account, affected databases, retained origins, and evidence of new connections. Add the change time and person authorized to restore a precise rule. If server rules or indirect paths remain outside your visibility, assign verification to the provider. Limited confirmation remains useful when it specifies what was examined.

Remote Database Access is a cPanel feature the host can expose or hide. Removing an entry from an already equipped account requires no new tool subscription in this procedure. Network capabilities, shell access, and support intervention depend on the contract. Have scope confirmed before planning a change affecting several databases.

Review this inventory at the next migration or end of a remote engagement. An entry with a service name and owner is easier to handle than an isolated address without a comment. The evidence to retain remains the relationship between a rule, an origin, and an identified consumer.

The WordPress Workshop.

Build an access record before deleting a rule

On a private sheet, create five columns: consumer, database, SQL user, origin actually seen by the server, and next execution. A fictional row might be “current WordPress; store database; site account; 192.0.2.20; continuous.” Another: “weekly export; same database; export account; 198.51.100.30; Sunday.” Account names distinguish uses; no password belongs here.

Suppose the old origin is 192.0.2.10. An exact entry 192.0.2.10 and a pattern 192.0.2.% may cover it simultaneously. Deleting only the first therefore does not establish refusal. Have other consumers covered by the pattern attributed before narrowing it. The % pattern documented by cPanel is broad authorization; it is not a CIDR mask to copy into a firewall.

After the change, record the time of a successful fresh connection for every retained consumer. For the old one, write “refusal observed from this origin” only if the test actually occurred with the correct destination and credentials. Otherwise, write “rule removed, refusal not tested.” This distinction makes handover usable without presenting a simple cPanel click as complete validation.