This is one of those events that you can only chalk up to experience, and one you will never repeat after the fact. When importing into WordPress using custom scripts, typically during a migration task for a new build, a WordPress constant unbeknown to me at the time can cause chaos.

If you want the tl;dr without the accompanying story, just make sure to set the following constant to true before your executing your import script.

/**
 * Define this constant true to prevent pingbacks on
 * links in the imported body copy on save_post
 */
define('WP_IMPORTING', true);

With that said, let us take a look at WordPress core and discover why this works and what it actually controls during the importing of posts. After a quick search through the WP core codebase, the first hit for WP_IMPORTING is within a file named wp-class-importer.php which handles many of the native import functionality, at line 258 we have a class method that is clearly attempting to stop something spiraling out of control during importing of content.

public function stop_the_insanity() {
  global $wpdb, $wp_actions;
  // Or define( 'WP_IMPORTING', true );
  $wpdb->queries = array();
  // Reset $wp_actions to keep it from growing out of control.
  $wp_actions = array();
}

The main instance of the constant is however in the file wp-includes/post.php which as the name would imply handles the majority of the functionality around creating, updating, editing, and removing posts. On line 7394 the function _publish_post_hook() has a early exit if block that checks if the constant has been previously defined. If the constant has not been defined and the option default_pingback_flag is truthy it will continue on and schedule a wp_cron event to fire off pingbacks for all links found within the content which has been inserted into the post_content column in wp_posts.

Hold on... can we not just set this option instead of the constant?

Yep you can if that works for you, however as it needs to be set via the admin, I know I would end up forgetting to check it or set it when spinning up a new local environment to test out a import procedure. Defining the constant at the beginning of the import script appears to be a more robust approach. You could also look to dynamically set the option with update_option() and that would be another valid way to prevent this.

I believe by default on a fresh install, default_pingback_flag is switched off however in this specific instance it was turned on and I wasn't aware.

So did I DDOS our clients production site?

Yes, yes I did and they logged a ticket on our support portal with a list of the 26,000 pingbacks I had triggered while importing 20 odd years of articles. The real key piece evidence that it was me, was the origin IP address of the WordPress site making the requests from my local environment.

So don't be like me and DDOS your clients production site during a standard migration import. Believe me when I say it typically doesn't go down too well.