MageCart attack on Newegg

I doubt we'll get to know the exact details of how they were able to put the malicious JavaScript on newegg.com. For that to happen, newegg.com would likely need to provide the public with undisclosed information about their private infrastructure.

Speaking in general terms, the answer is that... something was insecure on their server or within their software. There are virtually unlimited possibilities of how this may have happened.

The following detail is interesting:

A key date in the Magecart attacks against Newegg come from the registration data of the neweggstats.com domain

This implies that the forensics team at Volexity were not able to determine when the attack began using data found on newegg.com's server. For instance, files that had been touched may have had their timestamps reverted to their pre-modified dates. Their estimate of when the compromise began is based on a domain registration date... but maybe the attacker had been using a less convincing domain for a long time before deciding to switch to neweggstats.com.

A few common possibilities are below.

SQL Injection

An attacker may be able to discover enough about your database schema to learn that the contents of a given table/column are inserted into every page without sanitization. The attacker may then discover an SQL Injection point and be able to INSERT a script tag into the given table/column. The software would then happily include the attacker's malicious JavaScript on the page.

Phishing for admin credentials

The administrative portion of the website may openly allow script tags to be included in the site's layout in some way. This could include general template editing (ability to make changes to the website's HTML using an editor) or it could be something like an admin tool that allows you to upload payment images for the checkout pages (technically, this is the same as the first example).

The software might even allow an admin to simply upload a JavaScript file that would automatically be included on the website.

Providing value

Any third party JavaScript that you include on your website has the ability to be malicious. One could simply advertise a service for advanced ecommerce analytics to get their malicious code included on your site. Then the site owner would do the hard work for you.

Unsecured image uploads

Images can contain executable code. Some sites allow users to upload photos with their product reviews. If newegg.com allowed this, but did not sanitize the images, then an attacker would be able to get their executable code on the server easily. Once on the server, the attacker would need to cause the server to "run" the image as code. This can be done if your server is misconfigured or if your software has a security hole that would allow the image to be included as code. The malicious executable would then run with the same permissions as the webserver (or worse). At that time the software could append code to an already included JavaScript file on the server.

Summary

Writing software and making it secure are very different tasks. Sometimes a company puts emphasis on adding features because the folks that run the company are primarily interested in their profits. The idea that labor should be invested in securing their software never even crosses their minds until after a breach has taken place.

Often the employees who might be responsible for securing their software are inexperienced, underpaid, overworked, or inherit insecure systems from previous employees. When no one has the job of securing your server / software, vulnerabilities find their way in.

The method(s) an attacker may use to compromise a site is usually multi-faceted and may not be completely understood even after the compromise is discovered. Hiring a forensics company can be helpful, but their abilities may be limited due to the server's configuration (for instance, logs may only be stored for a short period of time).