עדכוני וורדפרס: הבסיס לאבטחה שלך

by | וורדפרס

אם אי פעם ראיתם תוסף "נטוש" שממשיך לעבוד... כנראה שכבר נשאתם פצצת זמן בלי לדעת זאת.

תנאים מוקדמים גיבוי עדכני (קבצים + מסד נתונים), גישת מנהל וורדפרסובאופן אידיאלי גישת FTP/SFTP ללוח הבקרה של האירוח. הדוגמאות שלהלן מתמקדות וורדפרס 6.9.4 (אפריל 2026) ו- PHP 8.1 +לעולם אל תשנו את קבצי הליבה של וורדפרס: כל הקשחה חייבת להתבצע דרך תצורת השרת. wp-config.php, או קוד בתוסף ייעודי.

האיום

עדכון לוורדפרס, בין אם זה עבור ערכת נושא או תוסף, אינו "נוחות". לעתים קרובות מדובר בתיקון אבטחה שסוגר פגיעות ידועה. וכאשר פגיעות ידועה, היא נבדקת כל הזמן על ידי בוטים.

מה תוקף יכול לעשות אם האתר שלך מפגר

  • קח שליטה על חשבון מנהל מערכת (באמצעות פגיעות של הסלמת הרשאות או חטיפת סשן).
  • הזרקת ספאם של SEO (דפים נסתרים, קישורים יוצאים, הפניות), מה שבסופו של דבר מכביד על התנועה שלך.
  • התקנת דלת אחורית (webshell, תוסף מזויף, mu-plugin) לחזור אפילו לאחר "ניקוי" שטחי.
  • גניבת נתונים (אימיילים, טפסים, הזמנות WooCommerce) תלוי במה שאתם מאחסנים.
  • שימוש בשרת שלך כדי לתקוף אתרים אחרים (שליחת דואר זבל, סריקות), מה שעלול להוביל לחסימת ספק האירוח.

למה זה כל כך נפוץ בפועל?

התקפות אופורטוניסטיות (לא ממוקדות) הן ללא ספק הנפוצות ביותר: בוטים סורקים את האינטרנט בחיפוש אחר גרסאות ידועות וקבצים אופייניים. מניסיוני, אתרים שנפגעו "ללא סיבה" כמעט תמיד נפגעים מאחת הסיבות הבאות:

  • תוסף פופולרי שלא עודכן במשך חודשים;
  • ערכת נושא פרימיום שעודכנה "ביד" אך מעולם לא סונכרנה בפועל;
  • גרסת PHP מיושנת שמאלצת משתמשים להיצמד לגרסאות ישנות של תוספים;
  • סביבת בימוי נעדרת, ולכן עדכונים נדחים "מחשש לשבור דברים".

הסיכון מוסבר בפשטות

כאשר פותחים תיקון לנקודת תורפה, המידע הופך לעיתים קרובות לציבור (הערות שחרור, קבצי CVE, יומני שינויים, קבצי commit). תוקפים אינם צריכים להמציא שום דבר חדש: הם פשוט משתמשים שוב בפגיעות. אם לא מיישמים את התיקון, נשארים על הגרסה הפגיעה, עם מטרה שקל מאוד לזהות.

סיכום קצר

  • עדכון פירושו סגירת פגיעויות שכבר תועדו.בוטים מחפשים במיוחד גרסאות מיושנות.
  • וורדפרס 6.9.4 + PHP 8.1+ אם האחסון שלך חוסם את PHP, אתה חוסם גם את התיקונים שלך.
  • תוספים/תבניות הם משטח ההתקפה מספר אחת באתרי רוב הבלוגרים.
  • לפחות עדכוני אבטחה יהיו אוטומטייםולבחון את השאר על תפאורה מבוימה.
  • שעון יומני רישום, חשבונות מנהל, קבצים שהשתנו, תוספים לא ידועים, משימות cron חשודות.
  • אם אתה בסיכון בידוד, שחזר מגיבוי נקי, ולאחר מכן תיקון + סיבוב של סודות.

קוד פגיע - מה לא לעשות

הנושא כאן הוא עדכונים. המלכודת הקלאסית בצד ה"קוד": השבת הגנות ou הטמע מנגנון עדכון מותאם אישית (לעתים קרובות עבור ערכות נושא פרימיום) אשר מורידה ומתקינה קוד ללא אימות קפדני.

הנה דוגמה מציאותית שראיתי באתרי אינטרנט: קטע טקסט שמוריד קובץ ZIP "עדכון" מכתובת URL ומתקין אותו. זה מתחיל מכוונות טובות ("אני רוצה לעדכן אוטומטית את ערכת הנושא שלי"), אבל זה אסון.

<?php
/**
 * EXEMPLE DANGEREUX : ne faites pas ça.
 * Problèmes :
 * - Téléchargement depuis une URL non fiable
 * - Aucune vérification de signature / hash
 * - Aucune capacité vérifiée
 * - Peut être déclenché via une requête si mal protégé
 * - Risque d'installation de code arbitraire (RCE)
 */

add_action('init', function () {
	// Erreur fréquente : une "clé" faible ou exposée dans le code
	if (!isset($_GET['force_update']) || $_GET['force_update'] !== '1') {
		return;
	}

	$zip_url = isset($_GET['zip']) ? $_GET['zip'] : '';

	// Erreur : aucune validation d'URL, aucune liste blanche
	$tmp = download_url($zip_url);
	if (is_wp_error($tmp)) {
		return;
	}

	// Erreur : upgrader sans vérifier les droits
	require_once ABSPATH . 'wp-admin/includes/file.php';
	require_once ABSPATH . 'wp-admin/includes/misc.php';
	require_once ABSPATH . 'wp-admin/includes/class-wp-upgrader.php';

	$upgrader = new Plugin_Upgrader();
	$upgrader->install($zip_url);
});

כיצד פועלת ההתקפה (ללא "מדריך למשתמש")

קוד מסוג זה פותח דלת בת שתי קומות:

  • שחרור אם התוקף מוצא דרך לקרוא לכתובת ה-URL עם הפרמטרים הנכונים (או אם באג אחר מאפשר קריאה ל-hook הזה), הוא כופה התקנה.
  • מטען אם ניתן לשלוט בכתובת ה-ZIP, התוקף יכול להתקין תוסף המכיל דלת אחורית.

הנקודה המרכזית: זה לא וורדפרס ש"חלשה" כאןזוהי פתרון עוקף למנגנוני עדכון של וורדפרס, הכוללים אמצעי הגנה (יכולות, הודעות לא זמינות, מקורות, ממשק API של WordPress.org וכו').

טעות נפוצה נוספת היא השבתת עדכונים אוטומטיים כי "הם שוברים דברים", ואז לשכוח מזה. התוצאה: צוברים גרסאות פגיעות במשך חודשים.

קוד מאובטח - הטמעה נכונה

המטרה: להישאר מעודכנים בלי לירות לעצמך ברגלניתן לחלק את הגישה הנכונה לשלושה חלקים:

  • utiliser מנגנונים טבעיים וורדפרס (עדכונים אוטומטיים, WP-Cron, WP-CLI);
  • ליישם מדיניות: מכונית לבטיחות, בימוי לכל השאר ;
  • הוסף שכבת בקרה: יומני רישום, התראות ואמצעי הגנה.

מדד 1: הפעלת עדכונים אוטומטיים (ברמה הנכונה)

וורדפרס מנהלת עדכונים אוטומטיים באמצעות מספר קבועים ומסננים. לבלוג מתחיל, אני ממליץ בדרך כלל על:

  • עדכון אוטומטי של הליבה עבור גרסאות משניות ואבטחה;
  • עדכון אוטומטי של תוספים (לפחות אלו הקריטיים: אבטחה, מטמון, קידום אתרים, טפסים);
  • עדכון אוטומטי של נושאים רק אם אתם משתמשים בערכת נושא "יציבה" ויש לכם עדכון staging (אחרת, עדכון ידני מתוזמן).

איפה אני צריך לשים את הקוד? הנקי ביותר: א. תוסף mu (תוסף חובה), נטען אוטומטית ולא ניתן להשבית אותו מלוח הניהול. נתיב: wp-content/mu-plugins/צור את התיקייה אם היא לא קיימת, ואז קובץ לדוגמה security-updates-policy.php.

<?php
/**
 * Plugin Name: MU - Politique de mises à jour (sécurité)
 * Description: Politique de mises à jour pour WordPress 6.9.4+ (core/plugins/thèmes) + journalisation.
 * Author: Votre équipe
 * Version: 1.0.0
 *
 * À placer dans : wp-content/mu-plugins/security-updates-policy.php
 */

defined('ABSPATH') || exit;

/**
 * 1) Autoriser les mises à jour automatiques du core.
 * WordPress gère finement les mises à jour de sécurité ; on évite de bloquer.
 */
add_filter('allow_major_auto_core_updates', '__return_true');
add_filter('allow_minor_auto_core_updates', '__return_true');

/**
 * 2) Politique plugins/thèmes : activer par défaut les auto-updates des plugins,
 * mais laisser les thèmes en manuel (souvent plus risqué côté design).
 *
 * Note : l’UI WordPress permet aussi d’activer plugin par plugin.
 * Ici, on définit une base cohérente.
 */
add_filter('auto_update_plugin', function ($update, $item) {
	// $item->plugin ressemble à "akismet/akismet.php"
	// Exemple : on force l’auto-update pour tous les plugins
	return true;
}, 10, 2);

add_filter('auto_update_theme', function ($update, $item) {
	// Par défaut, on n’auto-update pas les thèmes pour éviter une casse visuelle non détectée.
	return false;
}, 10, 2);

/**
 * 3) Journaliser les mises à jour réalisées (utile pour audit).
 * WordPress déclenche des actions lors des upgrades.
 */
add_action('upgrader_process_complete', function ($upgrader, $hook_extra) {
	if (empty($hook_extra['type']) || empty($hook_extra['action'])) {
		return;
	}

	$type   = sanitize_text_field($hook_extra['type']);   // plugin|theme|core
	$action = sanitize_text_field($hook_extra['action']); // update|install|delete

	// On limite au "update"
	if ($action !== 'update') {
		return;
	}

	$message = sprintf(
		'[MAJ] Type=%s | Détails=%s | Date=%s',
		$type,
		wp_json_encode($hook_extra),
		gmdate('c')
	);

	// error_log écrit souvent dans le log PHP de l’hébergeur.
	// Alternative : envoyer vers un système de logs (Sentry, syslog, etc.).
	error_log($message);
}, 10, 2);

הסבר פשוט

Un וו היא נקודת הרחבה: וורדפרס "קוראת" לקוד שלך בזמן מסוים. פעולה מבצע קוד (למשל, לאחר עדכון). א מסנן משנה ערך (למשל, מאפשר או אוסר עדכון אוטומטי).

הסבר טכני (מה קורה מאחורי הקלעים)

וורדפרס מחליטה האם עדכון אוטומטי מותר על ידי שילוב קבועים, אפשרויות ומסננים. על ידי כפיית auto_update_plugin à trueאתה אומר, "אם וורדפרס תחליט שהעדכון רלוונטי, אז תמשיכו." אתה לא עוקף את הבדיקות המקוריות, אתה עובד איתן.

אמצעי 2: לעולם אל "תעדכנו" באמצעות הורדה שרירותית

אם אתם משתמשים בתבנית פרימיום (Avada, Divi 5 וכו'), השתמשו המנגנון הרשמי שלהם (רישיון + API) ולהימנע מ"קבצי ZIP מדרופבוקס". קובץ ZIP שנשלח בדוא"ל לעיתים קרובות מסתיים ב:

  • מאוחסן על מכונה נגועה;
  • הועלה מחדש ללא אימות;
  • מותקן בייצור ללא בדיקות.

עבור Divi 5 / Elementor / Avada: עדכונים מטופלים דרך WordPress והמחבר/רישיון המתאימים להם. זהו הנתיב שנהנה מבקרות WordPress (יכולות, אובייקטים לא פעילים, הרשאות).

אמצעי 3: ניטור גרסאות וחסימת סביבות מיושנות

אני נתקל לעתים קרובות באתרים ש"חסומים" מכיוון ש-PHP עדיין בגרסה 7.x, ולכן חלק מהתוספים מסרבים להתעדכן. כתוצאה מכך, הם נשארים בגרסה פגיעה עקב מגבלה טכנית. הרבה יותר טוב להציג אזהרה ברורה בפאנל הניהול.

איפה אני צריך לשים את הקוד? אפילו תוסף mu, או תוסף מותאם אישית. הימנעו functions.php אם אתם מתחילים: שגיאת תחביר עלולה לגרום נזק לאתר.

<?php
defined('ABSPATH') || exit;

add_action('admin_notices', function () {
	if (!current_user_can('manage_options')) {
		return;
	}

	$php = PHP_VERSION;
	if (version_compare($php, '8.1.0', '<')) {
		echo '<div class="notice notice-error">';
		echo '<p><strong>Sécurité : votre PHP est trop ancien (' . esc_html($php) . ').</strong> ';
		echo 'WordPress 6.9.4 fonctionne mieux en PHP 8.1+ et beaucoup de correctifs plugins exigent une version récente. ';
		echo 'Planifiez une mise à niveau PHP côté hébergeur.</p>';
		echo '</div>';
	}
});

תצורת שרת

עדכונים מפחיתים את הסיכון, אך לא מבטלים אותו לחלוטין. תצורת שרת טובה מגבילה את ההשפעה אם רכיב מסוים פגיע.

.htaccess (Apache): חסימת ביצוע PHP בספריות רגישות

אפאצ'י עדיין נפוץ בתוכניות אירוח שיתופי רבות. הרעיון: למנוע מ-PHP להריץ אותו ב wp-content/uploadsתוכנות זדוניות רבות מסתתרות שם.

איפה להדביק את זה? צור קובץ .htaccess ב wp-content/uploads/ (אם ספק האירוח שלך מאפשר זאת).

# wp-content/uploads/.htaccess
<FilesMatch ".php$">
  Require all denied
</FilesMatch>

אם ספק האירוח שלך משתמש בתצורת Apache ישנה, ​​לעיתים תראה וריאציות עם Deny from allמעדיפים תחביר מודרני (Require) כאשר זמין.

wp-config.php: השבתת עורך הקבצים (מפחית את ההשפעה של חשבון מנהל מערכת שנפגע)

אם תוקף מקבל גישת מנהל, עורך ערכות הנושא/תוספים בלוח הניהול הופך לקיצור דרך להחדרת קוד זדוני. השבתתו אינה מחליפה עדכונים, אך מסירה פגיעות מרכזית.

איפה להדביק את זה? Dans wp-config.php, למעלה /* That's all, stop editing! */.

define('DISALLOW_FILE_EDIT', true); // Empêche l'édition de fichiers via l'admin

כותרות HTTP: צמצום התקפות "קלאסיות" בצד הדפדפן

כותרות אלו אינן מתקנים פגיעות של תוסף, אך הן מפחיתות סיכונים קשורים (חטיפת קליקים, הזרקות). ב-Apache, ניתן להוסיף אותן ל-vhost או לפעמים ל- .htaccess si mod_headers הוא פעיל.

# Exemple Apache (dans .htaccess si autorisé)
<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>

עבור מדיניות אבטחת תוכן (CSP), יש להמשיך בהדרגה: באתרים המשתמשים ב-Elementor/Divi/Avada, CSP מחמיר מדי שובר במהירות את העורך. אני מתחיל לעתים קרובות עם... מצב "דוחות בלבד" בצד השרת, ואז אני מקשה את זה.

HTTPS ועדכונים: בדוק את השרשרת המלאה

עדכוני וורדפרס מסתמכים על חיבורי TLS. אם לשרת שלך יש אישורים שבורים, זמן מערכת שגוי או מגבלות רשת, תראה שגיאות הורדה. לפני שתתחיל להתעסק עם זה, תקן את הסיבה.

בדוק אם האתר שלך פגיע

אתה לא מחפש "פגיעות ספציפית". אתה מחפש אינדיקטורים רכיבים מאוחרים, קבצים שהשתנו, חשבונות חשודים, שגיאות חוזרות ונשנות.

WP-CLI: הכלי האמין ביותר לביקורת מהירה

WP-CLI הוא ממשק שורת פקודה עבור וורדפרס. אם ספק האירוח שלך מציע אותו, זה חוסך זמן עצום.

# Version WordPress
wp core version

# Vérifier les mises à jour disponibles (core)
wp core check-update

# Lister plugins et mises à jour
wp plugin list
wp plugin list --update=available

# Lister thèmes et mises à jour
wp theme list
wp theme list --update=available

# Mettre à jour (à faire d'abord en staging si possible)
wp plugin update --all
wp theme update --all
wp core update

מלכודת נפוצה הפעל פקודות אלו בסביבת ייצור מבלי לשמור. לכל הפחות, צור תמונת מצב, או ייצא את מסד הנתונים ואחסן את הקבצים בארכיון.

אימות שלמות קבצי הליבה

אם אתם חושדים בפריצה, התחילו בבדיקה אם שונו קבצי ליבה כלשהם.

# Vérifie les checksums officiels du core WordPress
wp core verify-checksums

אם פקודה זו מחזירה אי התאמות כלשהן, אל תיבהלו: ספקי אירוח מסוימים מוסיפים מדי פעם קבצים. עם זאת, קבצי ליבה שעברו שינוי הם אינדיקטור חזק.

SQL: זיהוי מנהלים בלתי צפויים (אבחון)

אם יש לך גישה ל-phpMyAdmin, תוכל לבדוק את רשימת חשבונות המנהל. המטרה אינה "למחוק באופן אקראי", אלא לזהות את החשבון הלא ידוע.

# Remplacez wp_ par votre préfixe si nécessaire
# Liste des utilisateurs ayant la capacité admin (approximation via meta)
# À exécuter dans un client MySQL (ou phpMyAdmin)
SELECT u.ID, u.user_login, u.user_email, um.meta_value
FROM wp_users u
JOIN wp_usermeta um ON um.user_id = u.ID
WHERE um.meta_key = 'wp_capabilities'
AND um.meta_value LIKE '%administrator%';

מלכודת נפוצה בלבול לגבי הקידומת (wp_לאתרים רבים יש קידומת מותאמת אישית. כניסה wp-config.php המשתנה $table_prefix.

יומנים: מה כדאי לחפש

  • הודעות חוזרות ונשנות לעבר /wp-admin/admin-ajax.php (לפעמים נורמלי, אבל חשוד אם גדול ומגיע מכתובות IP שונות);
  • שיחות אל /wp-json/ בכבישים שלעולם אינך משתמש בהם;
  • שגיאות 404 בקבצים אופייניים: wp-content/uploads/*.php, wp-content/mu-plugins/, וכו. ;
  • חיבורי מנהל בשעות חריגות.

תרשים אבחון (תסמינים נפוצים)

סימפטום סיבה סבירה אימות פתרון
הפניות לאתרים מפוקפקים הזרקת JS/PHP דרך תוסף פגיע או קובץ שעבר שינוי השווה קבצים, בדוק header.phpבדוק תוספים אחרונים שחזור מגיבוי נקי, עדכון, שינוי סיסמאות
דפי ספאם באינדקס יצירת תוכן אוטומטית (חשבון פרוץ) או הזרקת מסד נתונים חפש פוסטים לא ידועים, בדוק חשבונות מנהל הסרת תוכן, תיקון פגיעות, בקשת אינדוקס מחדש
לא ניתן לעדכן (הפסקת זמן / הורדה נכשלה) בעיות TLS/DNS, הרשאות קבצים, מכסת דיסק יומני PHP, שטח דיסק, בדיקת HTTPS יוצא תקן את השרת, ולאחר מכן הפעל מחדש את העדכונים.
האתר איטי פתאום כורי קריפטו, ספאם, עבודות cron זדוניות ניטור מעבד, בדיקת cron, תוספים לא ידועים ניקוי + הקשחה + ניטור
מסך לבן לאחר עדכון התנגשות בין תוספים/ערכות נושא, PHP מיושן, זיכרון מטמון יומני שגיאות, השבתת תוספים דרך FTP, בדיקת PHP התקנת PHP 8.1+, הפעלה באמצעות שלב (staging) והפעלה מחדש במידת הצורך.

שגיאות אבטחה נפוצות

שגיאה ריסק פתרון
דחיית עדכונים "מחשש לשבור משהו" חשיפה ממושכת לפגיעויות ידועות הגדרת בימוי + גיבויים + חלון תחזוקה
העתקת קטע קטע שנמצא בפורום אל functions.php שגיאה חמורה, או יצירת דלת אחורית לא מכוונת השתמש בתוסף mu / תוסף מותאם אישית, סקור, בדוק ב-staging
שכחת נקודה-פסיק / סוגריים האתר מושבת (שגיאה 500), לפעמים באמצע עדכון עריכה דרך IDE, הפעלת רישום, פריסה נקייה
שימוש ב-hook לא מתאים (למשל, ביצוע קוד מנהל מערכת על init) קוד מופעל בצד הציבורי, משטח תקיפה מורחב Utiliser admin_init, לבדוק current_user_can()נזירות
בדיקות ישירות בייצור הפרעה, אובדן נתונים, חזרה למצב קודם מסובכת הליך תכנון + פריסה
שכחה לנקות את המטמון (תוסף/CDN/דפדפן) אתה חושב "זה לא עובד", אתה חוזר על הליכים מסוכנים. ניקוי מטמון של תוסף + CDN + דפדפן לאחר עדכון
התקנת ערכת נושא/תוסף "בטלה" (פיראטית) דלת אחורית משולבת, פשרה כמעט ודאית השתמשו רק במקורות רשמיים וברישיונות תקפים.
היצמדות ל-PHP מיושן חוסם תיקונים, מגביר פגיעויות שדרגו ל-PHP 8.1+ (רצוי גרסה עדכנית יותר אם אפשר)
מבלבלים בין מניות ומסננים הגנה לא הוחלת (לדוגמה, עדכון אוטומטי מעולם לא הופעל) בדוק את תיעוד ה-hook, בדוק ותוכן רישום
קטע הקוד שבור על ידי תוסף קטע הקוד / ערכת נושא של צאצא מדיניות האבטחה הושבתה מבלי ששמת לב ריכוז בתוסף mu-plugin גרסה מוגדרת
קישורים קבועים לא נוצרו מחדש לאחר עדכון מבני משמעותי 404, התנהגויות ביזאריות שמובילות ל"תיקונים" מסוכנים שמור מחדש קישורים קבועים וניקוי מטמונים

רשימת בדיקה להתקשות

  • גיבויים : יומי (מסד נתונים) + שבועי (קבצים), בדיקת שחזור אמיתית.
  • הצגה שיבוט לבדיקת עדכונים עבור ערכות נושא/תוספים כבדים (Divi 5, Avada, חבילות גדולות).
  • ליבה מעודכנת אתה נמצא ב 6.9.4 או עדכני יותר, ואתם מיישמים את המקצועות המשניים במהירות.
  • תוספים : הסר את אלה שאינם בשימוש (השבתתם לא תמיד מספיקה כדי להקטין את שטח הפנים).
  • נושאים : הסר ערכות נושא לא פעילות מיותרות (שמירה על ערכת נושא ברירת מחדל יכולה לסייע בפתרון בעיות).
  • PHP מִינִימוּם 8.1באופן אידיאלי, הגרסה היציבה המוצעת על ידי ספק האירוח התואם.
  • חשבונות מנהל ראשי אחד, השאר כעורך/כותב; אפשר 2FA במידת האפשר.
  • מפתחות סודיים : לחדש את בדיקות ה-SALT אם יש חשד (wp-config.php).
  • גישה SFTP במקום FTP; סיסמאות ייחודיות; אין שיתוף חשבונות.
  • קבצים חסום ביצוע PHP ב wp-content/uploads.
  • יומנים יש לאחסן למשך 7-30 ימים לפחות, ולנטר לאיתור חריגות.
  • WAF/CDN : הפעל חומת אש של אפליקציה אם זמינה (Cloudflare, Sucuri וכו').

מה אם האתר כבר נפגע?

אם אתם חושדים בפריצה, הימנעו מתגובת "אני אעדכן ויהיה בסדר". עדכון סוגר פגיעות, אך לא בהכרח מסיר את הדלת האחורית שכבר הותקנה.

  1. לְבוּדֵד העבר את האתר למצב תחזוקה (או חסום את המנהל), הגבל את הגישה במידת האפשר (רשימת היתרי IP מופעלת /wp-admin).
  2. שמור כראיה צור עותק של הקבצים + מסד הנתונים אוונגרד ניקיון. זה עוזר להבין את הערך.
  3. שינוי גישה קריטית סיסמאות וורדפרס, סיסמאות FTP/SFTP, סיסמאות מסדי נתונים, סיסמאות לחשבונות אירוח, מפתחות API. (כן, הכל.)
  4. בדוק את הליבה : wp core verify-checksumsאם הליבה שונתה, החלף אותה בגרסה נקייה.
  5. התקנה מחדש כראוי :
    • הורד עותק נקי של וורדפרס.
    • להחליף wp-admin et wp-includes,
    • אל תשמור בפנים wp-content מאשר מה שאתה שולט בו.
  6. בְּדִיקָה wp-content : חיפוש קבצים ששונו לאחרונה, .php ב uploadsתוספים לא ידועים של mu, תוספים "אקראיים".
  7. נקו את הבסיס : אפשרויות חשודות, משתמשי מנהל לא ידועים, תוכן שהוזרק.
  8. לְעַדְכֵּן core/plugins/themes לגרסאות הנוכחיות. הסר כל מה שהופסק.
  9. לְהַקְשִׁיחַ חסום PHP בהעלאות, סגור את העורך, הפעל 2FA, WAF.
  10. ניטור למשך 72 שעות יומני רישום, קבצים חדשים, עבודות cron חדשות, מנהלים חדשים.

אם יש לכם עסק של מסחר אלקטרוני או מידע רגיש, שתפו את ספק האירוח שלכם, ובהתאם לתחום השיפוט שלכם, בדקו את חובותיכם (למשל, הודעה). אל תמעיטו בסיכון: פרצת נתונים לרוב שקטה.

טיפים לתחזוקה ותאימות

קצב ריאליסטי (למתחילים)

  • כל שבוע עדכוני תוספים + כורה ליבות, ניקוי מטמון, בדיקה מהירה של הקצה הקדמי.
  • כל חודש ביקורת תוספים (הסרת מה שכבר לא בשימוש), אימות מנהל, בדיקת שחזור.
  • כל רבעון סקירת ביצועים, סקירת אבטחה, הקשחת שרתים במידת האפשר.

תאימות Divi 5 / Elementor / Avada: מה באמת שובר את זה

בוני דפים כמעט ולא קורסים "בגלל וורדפרס". הם קורסים בגלל:

  • תוסף נוסף מזריק JS/CSS לא תואם;
  • מטמון אגרסיבי משרת קבצים ישנים;
  • מיניפייר משלב סקריפטים בצורה גרועה;
  • עדכון משמעותי לבונה משנה מודול.

השגרה שלי באתרי Elementor/Divi/Avada:

  • בימוי (staging) הוא חובה עבור עדכוני בונה וערכות נושא;
  • עדיפות ניתנת לעדכון תוספים/תיקוני אבטחה;
  • לאחר העדכון: ניקוי מטמון (תוסף + שרת + CDN) ואימות של 3 דפים מרכזיים (דף הבית, מאמר, יצירת קשר).

קידום אתרים וביצועים: אבטחה "מונעת" אסונות

אתר אינטרנט נגוע לעיתים קרובות מסתיים ב:

  • דפי ספאם באינדקס
  • הפניות ניידות,
  • ירידה פתאומית ב-Core Web Vitals (סקריפטים מוזרקים),
  • התראה על "אתר פרוץ" ב-Search Console.

עדכון קבוע גם עוזר למנוע שבועות של התאוששות מקידום אתרים.

שתי עצות מעשיות מאוד כדי למנוע הפתעות לא נעימות

  • התאם אישית את הפוליסה שלך תוסף mu פשוט (כמו זה שלמעלה) עדיף על 10 קטעי קוד מפוזרים.
  • הימנעו ממדריכים ישנים קטעי טקסט רבים משנים 2018–2022 משתמשים בתבניות מיושנות או מתעלמים מ-PHP 8.1+. אם קוד דוחף אותך לשנות את הליבה, התעלם ממנו.

משאבים

שאלות נפוצות

האם אני צריך להפעיל את כל העדכונים האוטומטיים?

לבלוג מתחיל, אני ממליץ לכל הפחות: עדכונים אוטומטיים עבור הליבה (תיקוני אבטחה/מינוריים) ותוספים. עבור תבניות (במיוחד עם Divi 5 / Avada), עדיף להשתמש בעדכון מתוזמן עם שלב (staging), אלא אם כן יש לכם תהליך בדיקות חזק.

למה תוספים מסוכנים יותר מוורדפרס עצמה?

ליבת וורדפרס עוברת ביקורת קפדנית, ותיקונים יוצאים במהירות. איכות התוספים משתנה, וחלקם מופסקים. תוסף פופולרי אך לא מתוחזק הופך למטרה מושלמת.

האם עדכון יכול "לשבור" את האתר שלי?

כן, במיוחד באתרים עם הרבה הרחבות, אחסון אגרסיבי במטמון או בוני תוכנות. התשובה אינה לא לעדכן: אלא לבדוק במצב staging, לגבות את האתר וליישם חלון תחזוקה.

היכן עליי להדביק את קוד האבטחה: functions.php, plugin, או mu-plugin?

ליתר ביטחון, אני מעדיף את תוסף mu הוא תמיד נטען, ותבנית לא יכולה להשבית אותו. functions.php מקובל למטרות ויזואליות, אך שגיאת תחביר עלולה בקלות לשבש את האתר.

אין לי WP-CLI. מה עליי לעשות?

ניתן לנהל עדכונים מפאנל הניהול של וורדפרס (לוח בקרה → עדכונים). ביקורת על "קבצים שעברו שינוי" קשה יותר ללא WP-CLI: שאלו את ספק האירוח שלכם אם הוא יכול להפעיל זאת, או השתמשו בתוסף אבטחה בעל מוניטין לסריקה.

מה המשמעות של "אין" ומדוע זה נדון בהקשר של אבטחה?

Un שליח וורדפרס משתמשת ב-nonce כדי למנוע התקפות CSRF (האלו כופות על מנהל מחובר לבצע פעולה). אם יש לכם טפסי ניהול (למשל, כפתור "עדכון"), nonce מונע הפעלת פעולה ללא ידיעתכם.

האם השבתת תוסף פגיע מספיקה?

לא תמיד. אם התוסף כבר שימש כנקודת כניסה, הוא עדיין יכול להיות דלת אחורית במקום אחר. השבתתו מפחיתה את הפגיעות, אך אם אתם חושדים בפריצה, בצעו ביקורת מלאה.

למה לחסום PHP בהעלאות?

כי uploads אמור להכיל מדיה (תמונות, קבצי PDF), לא קוד בר ביצוע. זיהומים רבים מפילים .php בתיקייה זו ולאחר מכן הפעל אותו דרך הדפדפן.

ספק שירותי האחסון שלי משתמש ב-PHP 8.0. האם אני באמת צריך לשדרג לגרסה 8.1+?

כן. בשנת 2026, הישארות על גרסה 8.1 תגרום לכם להיתקל באופן קבוע בחסימות עדכונים (תוספים שמתקינים את הדרישות המוקדמות שלהם) ותמנע מכם לקבל תיקוני זמן ריצה. ראו את הדף הרשמי עבור גרסאות נתמכות: php.net.

איך אפשר לדעת אם תוסף "נטוש"?

בספריית WordPress.org, בדקו את תאריך ה"עדכון האחרון", את התאימות שנבדקה ואת סטטוס התמיכה. אם תוסף לא עודכן זמן רב, החליפו אותו. מקור: תוספים של WordPress.org.

האם עדכון משפר את הביצועים?

לעיתים קרובות כן: תיקוני באגים, שיפורי שאילתות, תאימות PHP. אבל היתרון העיקרי נותר אבטחה: מניעת הדבקה חוסכת לכם הרבה זמן והפסדים בקידום אתרים.

פריטים קשורים

להשאיר תגובה

כתובת הדוא"ל שלך לא תפורסם. שדות חובה מסומנים *

אתר זה משתמש Akismet כדי להפחית דואר זבל. למד כיצד מעובדים נתוני ההערות שלך.