There's a large scale attack that's been going on since way back in April, and if that's what getting you then you'd have to add a trigger for every table in the database.
This script modifies the original attack code to clean up everything in one swoop, assuming <script isn't valid text anywhere in the db:
DECLARE @T varchar(255),@C varchar(255)
DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)
OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0) BEGIN
exec('update ['+@T+'] set ['+@C+']=LEFT(['+@C+'], CHARINDEX(''<script'', ['+@C+'])-1)
WHERE CHARINDEX(''<script'', ['+@C+']) >0')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
Additionally, I've heard you may have luck stopping this attack by removing SELECT permissions for the application user on syscolumns or sysobjects, if that's an option for you. You still need to fix your vulnerabilities in preparation for the next attack.