Unless the cron job that starts the morning news stream is owned by the same user account that is running httpd on that machine, a CGI process to kill the playback would need root privilege (or at least appropriate sudo permission). And as a web-based interface, that is not an attractive solution.

My first inclination would be to tailor the cron job so that it not only launches the audio stream player, but also watches (say, at 1 or 2 sec intervals) for the presence of a "stop.playback" file in some designated path. (This means the playback has to be launched as a background process, so the main script being run by cron can continue to operate.) Then the web interaction simply consists of creating the "stop.playback" file on demand, and the cron job script, on seeing this file, kills its child playback process, deletes the file, and exits.

(update: assuming it can happen that the child playback finishes normally (or can be said to be "done") before some unrelated CGI action creates the "stop.playback" file, the cron script would need to check for this condition as well, and exit. You probably don't want today's instance to still be running when cron starts tomorrow's instance.)