Tag: domain protection

  • Is your website at risk to the new widespread PHP vulnerability? What’s happening and how to make sure your website is secure

    Is your website at risk to the new widespread PHP vulnerability? What’s happening and how to make sure your website is secure

    A newly disclosed set of critical security vulnerabilities in PHP, one of the most widely used programming languages on the internet, has prompted urgent warnings to website owners, developers, and IT administrators. The vulnerabilities, collectively known as PHP2Shell, could allow attackers to remotely execute malicious code on affected servers without needing a username or password. Because PHP supports millions of websites and business applications, the potential impact extends well beyond traditional website security.

    On October 21, 2026, PHP developers released emergency security updates addressing two vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619. Both received a critical severity rating of 9.2 out of 10, and security researchers have demonstrated how they can be exploited to execute code on vulnerable systems. According to reporting from BleepingComputer, the vulnerabilities affect multiple PHP server configurations, making prompt patching essential for organizations that rely on the language.

    PHP is a server-side programming language responsible for generating dynamic website content, processing forms, managing user sessions, and supporting many popular web applications. Content management systems such as WordPress, Drupal, and Joomla rely on PHP, as do numerous business applications and custom-built platforms. PHP typically runs behind the scenes, so website owners may not even realize their sites depend on it.

    The PHP2Shell vulnerabilities involve problems in how PHP manages memory while processing requests. Under certain conditions, an attacker can manipulate these processes to execute instructions on the underlying server, potentially allowing them to access sensitive information, modify website files, or deploy additional malicious software. What makes these vulnerabilities particularly serious is that exploitation may not require an attacker to authenticate, and some affected configurations can be compromised before the website’s own application code begins running.

    How do you know if your website is at risk? Any website or application running an affected version of PHP should be evaluated, particularly if it can be accessed over the internet. This includes WordPress websites, e-commerce platforms, customer portals, and internally developed PHP applications. The risk is not limited to public-facing websites, either. Internal business applications that use PHP may also be vulnerable, especially if attackers can reach them through compromised networks or other exposed systems.

    Importantly, a website does not become secure against PHP2Shell simply because its particular installation, themes, or plugins are up to date. The vulnerabilities exist within the PHP runtime itself, meaning that fixing them requires updating the underlying PHP environment. Conversely, websites that do not run PHP are not directly affected by these particular vulnerabilities, although their servers, hosting environments, and other software may still have unrelated security risks.



    There is also evidence that attackers began attempting to exploit PHP2Shell even before the vulnerabilities were publicly disclosed. On October 22, Infosecurity Magazine reported that Amazon had detected an exploitation attempt four days before disclosure, with additional evidence of attacks taking place in the wild. The widespread use of PHP makes these flaws especially attractive to attackers who can automate their attempts against large numbers of internet-facing systems.

    That does not mean every PHP-based website has been compromised, and the presence of a vulnerable PHP version is not proof that an attack succeeded. However, organizations should treat these vulnerabilities as an urgent security issue rather than waiting for evidence of an attack. As The Washington Post reported, the severity of the flaws prompted warnings that some systems unable to receive immediate updates should be temporarily taken offline to reduce exposure.

    The first step is determining whether your website or business applications use PHP and identifying which versions are installed. If you use a managed hosting provider, your hosting dashboard may display the PHP version associated with your website, or the provider’s support team can confirm it for you. Businesses hosting their own infrastructure should work with their IT administrator or developer to inventory all PHP installations, including those used by internal applications that may have been overlooked during previous maintenance.

    PHP has released patched versions addressing these vulnerabilities, and organizations should verify that their environments are running an appropriate fixed release. The versions containing the emergency fixes are listed below, although newer supported releases may also include the patches. Systems running PHP 8.1 or older require special attention because those branches no longer receive regular upstream security updates, and organizations may need to migrate to a supported version or obtain a verified vendor-maintained patch.

    If your website or application uses an affected PHP version, updating the PHP runtime should be your immediate priority. Before making changes, create a verified backup of your website files, application configuration, and databases. Next, check your hosting provider’s control panel for a supported PHP update or ask your developer or IT provider to install the relevant security patches. After updating, restart the affected PHP services if your environment requires it, and test the website or application to confirm that important functionality continues working correctly. A recent report from SecurityWeek confirms that emergency fixes are available for supported PHP branches.

    For organizations managing their own web servers, patching should include checking every PHP runtime installed on the system, not just the version displayed by the main website. Older applications, separate hosting environments, and independently managed services may use different PHP installations. If an immediate update is not possible, temporarily restricting access or taking vulnerable services offline may be necessary until they can be secured. Configuration changes, web application firewalls, and additional monitoring can help reduce some risks, but they should not be considered replacements for installing the security updates.

    Applying the security update addresses the known vulnerabilities, but it does not automatically reverse any damage caused by an earlier compromise. Organizations should review their web server and PHP error logs for unusual activity, investigate unexpected file changes, and check for unfamiliar administrator accounts or processes. If there is evidence that an attacker accessed the system, additional incident response work may be necessary, including examining affected databases, removing malicious files, and rotating potentially exposed credentials.

    This incident is also a useful reminder to review your organization’s broader application maintenance practices. Website security extends beyond updating plugins or occasionally checking whether a site is online. Businesses should maintain an inventory of the software supporting their websites and internal applications, know who is responsible for applying updates, and establish a process for addressing critical vulnerabilities as they emerge. Organization using third-party developers or managed hosting should confirm which security responsibilities belong to their providers and which remain with the business itself.

    So, what does this mean for your business? The PHP2Shell vulnerabilities illustrate how a security flaw in a widely used software component can affect thousands of otherwise unrelated products and services. A business may maintain a well-designed website, use strong passwords, and follow good security practices while still being exposed through an outdated server component. The availability of emergency patches provides a clear path to reducing that risk, but businesses need to act promptly and verify that updates have actually been applied.

    If your organization relies on a PHP-powered website, customer portal, or business application, now is the time to contact your hosting provider, developer, or IT support team and confirm its patch status. At Geeks for Business, we help businesses identify vulnerable systems, coordinate security updates, and review their environments for potential exposure.

    Knowing what software your business depends on and keeping it properly maintained remains one of the most effective ways to prevent avoidable security incidents. Advice for issues like this is one benefit of partnering with a Managed Service Provider (MSP) like Valley Techlogic. If you would like specialized guidance for this issue or any other technology based challenges your business is facing, learn more today through a consultation.

    This article was powered by Valley Techlogic, leading provider of trouble free IT services for businesses in California including Merced, Fresno, Stockton & More. You can find more information at https://www.valleytechlogic.com/ or on Facebook at https://www.facebook.com/valleytechlogic/ . Follow us on X at https://x.com/valleytechlogic

  • Are your emails not getting through? Changes to Google and Yahoo DMARC Policy might be to blame

    Are your emails not getting through? Changes to Google and Yahoo DMARC Policy might be to blame

    Email deliverability can be tricky to guarantee, and now with recent changes to Google and Yahoo’s DMARC policies getting your emails delivered to your customers and prospects may be even more difficult.

    First, we should start out by explaining what DMARC is, DMARC or Domain Based Message Authentication is the process that checks to make sure the email that’s being sent is being sent from the domain it’s proclaiming to be. Its main purpose is to protect against email spoofing, which is when you have an email that says it’s from @yourdomain.com but is really from @notyourdomain.com.

    Why is that important? Ideally you do not want potentially bad actors being able to masquerade as you on the web and contact your customers or potential customers. The hiccup is that setting up DMARC and the provisions that go into it (SPF or Sender Policy Framework and DKIM or DomainKeys Identified Mail) are not for the faint of heart.

    SPF and DKIM are the groundwork that is then checked by DMARC, and we apologize for throwing all of these acronyms at you, but we promise they’re important if you are a business who relies on email (and who in the current day and age doesn’t?). Especially if most of your customers have Gmail or Yahoo emails.

    Gmail and Yahoo have both updated their policies to take a tougher stance on emails being sent without these policies set in place. To put it simply, if you don’t have these setup your emails are going to be sent to the spam box or not reach your target at all.

    So how do you begin setting up, SPF, DKIM, and DMARC for your business?

    SPF (Sender Policy Framework):

    1. Access your DNS records: Log in to your domain registrar or DNS hosting provider where your domain’s DNS records are managed.
    2. Create or edit your SPF record: Locate your domain’s DNS settings and add a TXT record. If you already have an SPF record, you’ll need to edit it. If not, create a new one.
    3. Define your SPF policy: In the TXT record, specify which servers are authorized to send emails on behalf of your domain. This is done by listing the IP addresses or domain names of your authorized email servers. For example, if you use Google Workspace for your email, your SPF record might include something like: “v=spf1 include:_spf.google.com ~all”. This indicates that Google’s servers are allowed to send emails for your domain.
    4. Test your SPF record and Publish your SPF Record: Use SPF testing tools to verify that your SPF record is correctly configured. There are various online tools available for this purpose. Once you’re confident that your SPF record is set up correctly, save the changes in your DNS settings. It may take some time for the changes to propagate across the internet.
    5. Monitor and maintain: Periodically review your SPF record to ensure it remains accurate. If you change your email infrastructure, update your SPF record accordingly.

    DKIM (DomainKeys Identified Mail)

    1. Generate DKIM keys: You’ll need to generate a pair of DKIM keys – a private key and a public key. The private key will be used to sign outgoing emails, and the public key will be published in your domain’s DNS records for email receivers to verify the authenticity of your emails. This tool can be used to generate DKIM keys for you.
    2. Add DKIM DNS record: Log in to your domain registrar or DNS hosting provider where your domain’s DNS records are managed. Add a new TXT record to your DNS settings. This record should contain your DKIM public key along with some DKIM-related tags that specify the version, the domain, and the selector for your DKIM keys.
    3. Configure your email server: Set up your email server to sign outgoing emails using the private key you generated earlier. Most email servers have built-in support for DKIM signing, and you’ll usually need to specify the location of the private key and the DKIM selector.
    4. Test DKIM: Send a test email from your domain and verify that it’s properly DKIM-signed. You can use various online DKIM validation tools to check if your DKIM setup is correct.
    5. Monitor and maintain: Regularly monitor your DKIM setup to ensure that it’s functioning correctly. If you change your email infrastructure or rotate your DKIM keys, remember to update your DKIM DNS record accordingly.

    DMARC (Domain-based Message Authentication)

    1. Create a DMARC policy: Determine what action you want email receivers to take when they receive emails that fail DMARC authentication. Options include monitoring (no action), quarantining (sending suspicious emails to spam folders), or rejecting (blocking suspicious emails).
    2. Publish your DMARC record: Log in to your domain registrar or DNS hosting provider and add a TXT record to your domain’s DNS settings. This record contains your DMARC policy along with additional information such as the email address where DMARC reports should be sent.
    3. Monitor and maintain based on DMARC reports: Configure your email system to generate DMARC reports and send them to the specified email address. These reports provide valuable information about how your domain is being used for email, including details about SPF and DKIM alignment.

    We hope the breakdown of how to setup these policies was helpful, but if you’re looking at this list and thinking there’s no way I can implement this on my own then that is where Valley Techlogic can help.

    We have helped our clients navigate domain challenges and answer technical questions such as how to improve email deliverability on top of providing IT solutions that help navigate other day to day technological challenges. Get started with us today.

    Looking for more to read? We suggest these other articles from our site.

    This article was powered by Valley Techlogic, an IT service provider in Atwater, CA. You can find more information at https://www.valleytechlogic.com/ or on Facebook at https://www.facebook.com/valleytechlogic/ . Follow us on Twitter at https://x.com/valleytechlogic.